Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
SI APPLICA A:
2013 
2016 2019 Subscription Edition SharePoint in Microsoft 365
In questo articolo viene fornita una panoramica di come pianificare e gestire in modo efficace la capacità di ambienti SharePoint Server 2013. Viene descritto inoltre come ottenere una buona conoscenza dei requisiti di capacità e delle funzionalità della distribuzione sulla base dell'analisi dei dati sulle prestazioni e sul volume. Viene esaminato infine l'impatto prodotto dalle applicazioni sulla capacità, inclusi l'utilizzo e le caratteristiche del contenuto.
Importante
[!IMPORTANTE] Alcuni valori presenti in questo articolo si basano sui risultati dei test e su altre informazioni relative a Prodotti SharePoint 2010 e potrebbero non rappresentare i valori finali per SharePoint Server 2013. L'articolo verrà aggiornato con i valori appropriati, collegamenti a contenuto correlato e altre informazioni e verrà ripubblicato quando saranno disponibili dati relativi a SharePoint Server 2013.
La gestione della capacità è un processo in continua evoluzione, poiché nessuna implementazione rimane statica in termini di contenuto e utilizzo. È necessario effettuare una pianificazione tenendo conto di esigenze di espansione e modifica, in modo che il proprio ambiente basato su SharePoint Server 2013 rappresenti sempre una soluzione aziendale efficace.
La pianificazione della capacità è solo una parte del ciclo di gestione della capacità. Rappresenta la serie iniziale di attività che consente agli architetti della struttura di individuare un'architettura iniziale più adatta per la distribuzione di SharePoint Server 2013. Il modello di gestione della capacità include ulteriori operazioni di convalida e ottimizzazione dell'architettura iniziale e fornisce un ciclo di commenti per la ripianificazione e l'ottimizzazione dell'ambiente di produzione finché non vengono supportati gli obiettivi di progettazione con scelte ottimali per quanto riguarda componenti hardware, topologia e configurazione.
Glossario
Nella documentazione relativa alla gestione della capacità di SharePoint Server 2013 vengono utilizzati i termini specifici illustrati di seguito.
RPS Acronimo di Requests Per Second, ovvero richieste al secondo. 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. Il numero di richieste elaborate da una farm è maggiore del numero di caricamenti delle pagine e di interazioni degli utenti finali. In ogni pagina infatti sono contenuti diversi componenti, ognuno dei quali crea una o più richieste quando viene caricata la pagina. Alcune richieste sono meno onerose rispetto ad altre in termini di transazioni. Nei test di laboratorio e nei documenti relativi ai case study sono state rimosse 401 richieste e risposte (handshake di autenticazione) dalle richieste utilizzate per il calcolo di RPS a causa dell'impatto irrilevante sulle risorse delle farm.
Ore di punta L'ora o le ore del giorno in cui la farm viene sottoposta al carico massimo.
Carico di picco La media del carico massimo giornaliero della farm, misurata in RPS.
Sovraccarico Carichi di picco transitori che non si verificano nelle ore di punta. Possono essere causati da aumenti imprevisti di traffico di utenti, da una riduzione della velocità effettiva della farm durante le operazioni amministrative o da una combinazione di fattori di questo tipo.
Scalabilità verticale Aggiunta di risorse, ad esempio processori o memoria, a un server.
Scalabilità orizzontale Aggiunta di ulteriori server a una farm.
Destinatari degli articoli sulla gestione della capacità
Esaminare le affermazioni seguenti per informazioni sui destinatari di questo contenuto.
Valutazione di SharePoint Server 2013
Importante
Alcuni collegamenti in questa sezione possono riferirsi a SharePoint Server 2010 e ad altre versioni precedenti del prodotto e verranno aggiornati non appena saranno disponibili versioni di questo contenuto relative a SharePoint Server 2013.
Sono un professionista IT o un decision maker aziendale e sto cercando una soluzione a problemi aziendali specifici. SharePoint Server 2013 è un'opzione per la distribuzione. Può fornire funzionalità e scalabilità che soddisfano i requisiti specifici?
Per informazioni sulla scalabilità di SharePoint Server 2013 per soddisfare la richiesta di soluzioni specifiche e per determinare i componenti hardware necessari per supportare tali requisiti, vedere le sezioni seguenti più avanti in questo articolo:
Per informazioni su come valutare SharePoint Server 2013 per le esigenze aziendali specifiche, vedere gli articoli seguenti:
Aggiornamento da Office SharePoint Server 2010
Attualmente si usa SharePoint Server 2010. Cosa è cambiato in SharePoint Server 2013 e cosa è necessario considerare se si esegue l'aggiornamento? Quale effetto avrà l'aggiornamento sulle prestazioni e sulla scalabilità della topologia?
Per informazioni su considerazioni di carattere più generale sull'aggiornamento e istruzioni su come pianificare ed eseguire un aggiornamento da Office SharePoint Server 2007, vedere l'articolo seguente:
Gestione e ottimizzazione di un ambiente attivo basato su SharePoint
È stato distribuito SharePoint Server 2013 e si vuole assicurarsi di disporre dell'hardware e della topologia appropriati. Come si convalida l'architettura e la si mantiene correttamente?
Per informazioni sul monitoraggio e sui contatori delle prestazioni per le farm di SharePoint Server 2013, vedere l'articolo seguente:
Per informazioni su come utilizzare gli strumenti di monitoraggio dell'integrità incorporati nell'interfaccia di Amministrazione centrale, vedere l'articolo seguente:
È stato distribuito SharePoint Server 2013 e si verificano problemi di prestazioni. Come è possibile risolvere i problemi e ottimizzare l'ambiente?
Per informazioni sul monitoraggio e sui contatori delle prestazioni per le farm di SharePoint Server 2013, vedere gli articoli seguenti:
Per informazioni sugli strumenti e sulle tecniche per l'ottimizzazione delle farm di SharePoint Server 2013, vedere l'articolo seguente:
Per informazioni su come risolvere i problemi utilizzando gli strumenti di monitoraggio dell'integrità incorporati nell'interfaccia di Amministrazione centrale, vedere l'articolo seguente:
Per un elenco degli articoli sulla gestione della capacità disponibili per funzionalità e servizi specifici di SharePoint Server 2010 (altri articoli verranno aggiunti man mano che saranno disponibili), vedere l'articolo seguente:
Per informazioni sulle dimensioni e le prestazioni dei database, vedere l'articolo seguente:
Per informazioni su Archiviazione BLOB remoti, vedere l'articolo seguente:
Dall'inizio alla fine
Si vuole sapere tutto sulla gestione della capacità di SharePoint Server 2013. Da dove comincio?
Per informazioni sui concetti generali su cui si basa la gestione della capacità e per i collegamenti a ulteriori documenti e risorse, vedere l'articolo seguente:
Per ulteriori informazioni sulla gestione della capacità, vedere gli articoli seguenti di integrazione a questo articolo introduttivo:
A questo punto si dovrebbe aver acquisito una certa familiarità con i concetti. Per informazioni sui limiti statici e configurabili di SharePoint Server 2013, vedere l'articolo seguente:
Quando si è pronti per identificare una topologia di partenza per l'ambiente basato su SharePoint Server 2013, è possibile esaminare la raccolta dei case study tecnici disponibili per individuare quello che corrisponde maggiormente ai propri requisiti. Per un elenco dei case study relativi a SharePoint Server 2010 (i case study su SharePoint Server 2013 verranno pubblicati man mano che saranno disponibili), vedere l'articolo seguente:
Per informazioni su come monitorare l'integrità e risolvere i problemi utilizzando gli strumenti di monitoraggio dell'integrità incorporati nell'interfaccia di Amministrazione centrale, vedere gli articoli seguenti:
Per ulteriori informazioni su come virtualizzare i server basati su SharePoint Server 2013, vedere l'articolo seguente:
Per ulteriori informazioni sulla disponibilità elevata e il ripristino di emergenza, vedere l'articolo seguente:
Quattro aspetti fondamentali delle prestazioni
La gestione della capacità si basa sui quattro aspetti fondamentali per il dimensionamento della soluzione elencati di seguito:
Latenza Ai fini della gestione della capacità, viene definita latenza il tempo che intercorre tra l'avvio di un'azione da parte di un utente, ad esempio la selezione di un collegamento ipertestuale, e il momento in cui viene trasmesso l'ultimo byte all'applicazione client o al Web browser.
Velocità effettiva Per velocità effettiva si intende il numero di richieste simultanee che possono essere elaborate da un server o da una server farm.
Volume di dati Il volume di dati si riferisce alle dimensioni del contenuto e al corpo di dati che il sistema è in grado di ospitare. La struttura e la distribuzione dei database del contenuto hanno un effetto significativo sul tempo necessario al sistema per elaborare le richieste (latenza) e sul numero di richieste simultanee che possono essere gestite (velocità effettiva).
Affidabilità L'affidabilità misura la capacità del sistema di soddisfare i target definiti per la latenza e la velocità effettiva nel tempo.
L'obiettivo principale della gestione della capacità di un ambiente consiste nel definire e gestire un sistema in grado di soddisfare i target di latenza, velocità effettiva, volume di dati e affidabilità della propria organizzazione.
Latenza
La latenza, conosciuta anche come latenza percepita dagli utenti finali, è costituita da tre componenti principali:
Il tempo di ricezione ed elaborazione della richiesta nel server.
Il tempo di trasferimento della richiesta e della risposta del server sulla rete.
Il tempo per il rendering della risposta nell'applicazione client.
Organizzazioni diverse definiscono obiettivi di latenza diversi in base ai requisiti aziendali e alle aspettative degli utenti. Alcune organizzazioni possono accettare una latenza di diversi secondi, mentre altre richiedono transazioni molto veloci. L'ottimizzazione per transazioni molto veloci in genere è più costosa e richiede client e server più potenti, versioni di browser e applicazioni client più recenti, soluzioni di rete con larghezza di banda elevata e possibilmente investimenti nello sviluppo e ottimizzazione delle pagine.
Vengono elencati di seguito alcuni dei fattori principali che determinano latenze percepite dagli utenti finali più lunghe ed esempi di alcuni problemi comuni. Questi fattori sono particolarmente importanti in scenari in cui i client sono geograficamente distanti dalla server farm o accedono alla farm attraverso una connessione di rete con larghezza di banda ridotta.
Funzionalità, servizi o parametri di configurazione non ottimizzati che possono rallentare l'elaborazione delle richieste e la latenza per i client remoti e locali. Per ulteriori informazioni, vedere Capacity management and sizing overview for SharePoint Server 2013 e Capacity management and sizing overview for SharePoint Server 2013 più avanti in questo articolo.
Pagine Web che generano richieste non necessarie nel server per il download di dati e risorse importanti. L'ottimizzazione prevede il download del numero minimo di risorse per la visualizzazione della pagina, la riduzione delle dimensioni delle immagini, l'archiviazione delle risorse statiche in cartelle che consentono l'accesso anonimo, il clustering delle richieste e l'abilitazione dell'interattività delle pagine mentre le risorse vengono scaricate in modo asincrono dal server. Queste ottimizzazioni sono importanti per ottenere un'esperienza di primo accesso accettabile.
Volume eccessivo di dati trasmessi sulla rete che incide negativamente sulla latenza e sulla velocità effettiva. Per le immagini e altri oggetti binari in una pagina ad esempio sarebbe opportuno utilizzare dove possibile un formato compresso, ad esempio png o jpg, anziché le bitmap.
Pagine Web non ottimizzate per caricamenti di pagine al secondo accesso. I tempi di caricamento delle pagine migliorano per i caricamenti delle pagine al secondo accesso perché alcune risorse delle pagine sono memorizzate nella cache del client e il browser deve scaricare soltanto il contenuto dinamico non memorizzato nella cache. Latenze inaccettabili per caricamenti di pagine al secondo accesso sono spesso causate da una configurazione errata della cache BLOB (Binary Large Object) o dalla disabilitazione della memorizzazione nella cache per i browser locali nei computer client. Le ottimizzazioni includono una corretta memorizzazione delle risorse nella cache del client.
Pagine Web con codice JavaScript personalizzato non ottimizzato. Questa situazione può rallentare il rendering della pagina nel client. L'ottimizzazione consiste nel rimandare l'elaborazione del codice JavaScript nel client finché non è stato caricato il resto della pagina e nel chiamare possibilmente gli script anziché aggiungere codice JavaScript incorporato.
Velocità effettiva
La velocità effettiva è indicata dal numero di richieste che possono essere elaborate da una server farm in un'unità di tempo e viene spesso utilizzata per misurare il volume delle operazioni che devono essere supportate dal sistema sulla base delle dimensioni dell'organizzazione e delle relative caratteristiche di utilizzo. Ogni operazione ha un costo specifico in termini di risorse della server farm. La conoscenza della domanda e la distribuzione di un'architettura della farm in grado di soddisfare costantemente la domanda richiedono un calcolo del carico previsto e l'esecuzione di test dell'architettura sotto carico per verificare che la latenza non sia fuori target in una situazione di concorrenza elevata e di sistema sollecitato.
Vengono elencati di seguito alcuni esempi comuni di condizioni di velocità effettiva ridotta:
Risorse hardware inadeguate Quando la farm riceve più richieste di quante non ne sia in grado di elaborare contemporaneamente, alcune richieste vengono accodate, il che comporta un ritardo cumulativo dell'elaborazione di ogni richiesta successiva finché la domanda non si riduce sufficientemente da consentire lo svuotamento della coda. Alcuni esempi di ottimizzazione di una farm per una velocità effettiva superiore includono le operazioni seguenti:
Verificare che i processori dei server della farm non siano utilizzati eccessivamente. Se ad esempio l'utilizzo della CPU nelle ore di picco o nelle situazioni di sovraccarico supera costantemente l'80%, aggiungere ulteriori server o ridistribuire i servizi in altri server della farm.
Verificare che nei server applicazioni e nei server Web sia disponibile memoria sufficiente per contenere la cache completa. In questo modo si eviteranno chiamate al database per la gestione di richieste per contenuto non memorizzato nella cache.
Verificare che nei server di database non vi siano colli di bottiglia. Se le operazioni totali disponibili di I/O al secondo su disco non sono sufficienti per supportare la domanda di picco, aggiungere altri dischi oppure ridistribuire i database nei dischi poco utilizzati. Per ulteriori informazioni, vedere la sezione Rimozione dei colli di bottiglia in Monitoraggio e manutenzione di SharePoint Server 2013.
Se l'aggiunta di risorse a computer esistenti non è sufficiente per risolvere i problemi di velocità effettiva, aggiungere server e ridistribuire le funzionalità e i servizi interessati nei nuovi server.
Pagine Web personalizzate non ottimizzate L'aggiunta di codice personalizzato in pagine utilizzate frequentemente in un ambiente di produzione è una causa comune di problemi di velocità effettiva. L'aggiunga di codice personalizzato può generare round trip aggiuntivi nei server di database o nei servizi Web per gestire le richieste di dati. La personalizzazione di pagine poco utilizzate può avere un effetto poco significativo sulla velocità effettiva, ma anche codice ottimizzato correttamente può rallentare la velocità effettiva della farm se viene richiesto migliaia di volte al giorno. Gli amministratori di SharePoint Server 2013 possono abilitare Dashboard sviluppatore per identificare il codice personalizzato che deve essere ottimizzato. Di seguito sono illustrati alcuni esempi di ottimizzazione del codice personalizzato:
Ridurre al minimo il numero di richieste di servizi Web e di query SQL.
Recuperare i dati richiesti minimi in ogni accesso al server di database limitando il numero di round trip necessari.
Evitare di aggiungere codice personalizzato in pagine utilizzate frequentemente.
Utilizzare gli indici quando si recupera una quantità di dati filtrata.
Soluzioni non attendibili La distribuzione di codice personalizzato in cartelle bin può comportare un rallentamento delle prestazioni dei server. Ogni volta che viene richiesta una pagina contenente codice non attendibile, in SharePoint Server 2013 devono essere eseguiti controlli di sicurezza prima che venga caricata la pagina. A meno che non vi sia un motivo specifico per la distribuzione di codice non attendibile, è consigliabile installare assembly personalizzati nella GAC per evitare controlli di sicurezza superflui.
Volume di dati
Per volume di dati si intende il volume di dati che possono essere archiviati dal server o dalla server farm continuando a soddisfare i target di latenza e velocità effettiva. Generalmente maggiore è il volume di dati nella farm, maggiore sarà l'impatto sulla velocità effettiva globale e sull'esperienza utente. Anche il metodo utilizzato per la distribuzione dei dati sui dischi e i server di database può influire sulla latenza e la velocità effettiva della farm.
Le dimensioni dei database, l'architettura dei dati e la presenza di componenti hardware sufficienti nei server di database sono tutti aspetti molto importanti per una soluzione di database ottimale. In una distribuzione ideale i database del contenuto sono dimensionati in base alle indicazioni sui limiti e vengono distribuiti in dischi fisici in modo che le richieste non vengano accodate a causa di un utilizzo eccessivo dei dischi e i server di database possano sopportare carichi di picco e situazioni di sovraccarico impreviste senza superare le soglie di utilizzo delle risorse.
Alcune operazioni inoltre possono bloccare determinate tabelle durante l'esecuzione. Nel caso ad esempio dell'eliminazione di un sito di grandi dimensioni, è possibile che le tabelle correlate nel database del contenuto in cui si trova il sito restino bloccate finché l'operazione di eliminazione non viene completata.
Vengono riportati di seguito alcuni esempi di ottimizzazione delle prestazioni dell'archiviazione e dei dati di una farm:
Verificare che i database siano distribuiti correttamente nei server di database e che le risorse dei server di database siano sufficienti per supportare il volume e la distribuzione dei dati.
Separare i volumi dei database in unità logiche (LUN, Logical Unit) univoche costituite da dischi fisici univoci. Utilizzare più dischi con tempo di posizionamento basso e configurazioni RAID appropriate per soddisfare le esigenze di archiviazione dei server di database.
È possibile utilizzare Archiviazione BLOB remoti se nel corpo sono contenuti molti oggetti binari di grandi dimensioni (BLOB, Binary Large Object). Archiviazione BLOB remoti offre i vantaggi seguenti:
I dati BLOB possono essere archiviati su dispositivi di archiviazione meno costosi che sono configurati per gestire l'archiviazione semplice.
L'amministrazione dell'archiviazione BLOB è controllata da un sistema progettato in modo specifico per l'utilizzo dei dati BLOB.
Le risorse del server di database vengono liberate per le operazioni di database.
Questi vantaggi non sono tuttavia esenti da conseguenze. Prima di implementare Archiviazione BLOB remoti in SharePoint Server 2013, è necessario valutare se tali vantaggi potenziali sono superiori ai costi e alle limitazioni correlati a tale implementazione.
Per ulteriori informazioni su come pianificare il volume di dati, vedere Pianificazione e configurazione dell'archiviazione e della capacità di SQL Server (SharePoint Server).
Affidabilità
L'affidabilità è la misura aggregata della capacità della server farm di soddisfare i target definiti per latenza, velocità effettiva e capacità dei dati nel tempo. In una farm affidabile il tempo di attività, i tempi di risposta, la frequenza degli errori, nonché la frequenza e l'entità dei sovraccarichi di latenza rientrano nei target stabiliti e nei requisiti operativi. Una farm affidabile può inoltre sostenere costantemente i target di latenza e velocità effettiva durante i carichi di picco e le ore di punta oppure quando vengono eseguite operazioni di sistema come la ricerca per indicizzazione o i backup giornalieri.
Per garantire l'affidabilità è importante tenere conto degli effetti di operazioni amministrative comuni sui target definiti per le prestazioni. Durante alcune operazioni, ad esempio la rigenerazione degli indici di database, l'esecuzione di processi timer di manutenzione o l'eliminazione di più siti con un elevato volume di contenuto, è possibile che il sistema non sia in grado di elaborare le richieste degli utenti abbastanza rapidamente. Questa situazione può avere ripercussioni sulla latenza e la velocità effettiva delle richieste degli utenti finali. L'impatto prodotto sulla farm dipende dalla frequenza e dal costo in termini di transazioni di queste operazioni meno comuni, nonché dall'eventualità che vengano eseguite durante le normali ore di utilizzo del sistema.
Vengono illustrati di seguito alcuni esempi per supportare un sistema più affidabile:
Pianificare processi timer e attività amministrative a elevato utilizzo di risorse durante le ore non di punta.
Implementare la scalabilità verticale per i componenti hardware nei server esistenti della farm oppure la scalabilità orizzontale aggiungendo server Web, server applicazioni o server di database aggiuntivi.
Distribuire in server dedicati i servizi e le funzionalità a elevato utilizzo di risorse. È inoltre possibile utilizzare un dispositivo di bilanciamento del carico per indirizzare il traffico specifico delle funzionalità a un server Web dedicato a funzionalità o servizi specifici.
Gestione della capacità e pianificazione della capacità
La gestione della capacità estende il concetto di pianificazione della capacità per descrivere un approccio ciclico, nel quale la capacità di una distribuzione di SharePoint Server 2013 viene continuamente monitorata e ottimizzata per adattarla a condizioni ed esigenze in evoluzione.
SharePoint Server 2013 offre una maggiore flessibilità e può essere configurato per supportare scenari di utilizzo in un'ampia gamma di punti di scala diversi. Non esiste un'unica architettura di distribuzione. Pertanto, i progettisti di sistema e gli amministratori devono comprendere i requisiti per gli ambienti specifici.
Modello di gestione della capacità di SharePoint Server 2013
Passaggio 1: modellazione Questo è il processo in base al quale si scelgono le soluzioni chiave che devono essere supportate dall'ambiente e si definiscono tutte le metriche e tutti i parametri importanti. Il risultato di questa sperimentazione è un elenco di tutti i dati chiave di cui è necessario disporre per progettare l'ambiente.
Valutare il carico di lavoro e il set di dati previsti.
Definire i target di prestazioni e affidabilità della farm.
Analizzare i log IIS per SharePoint Server 2013.
Passaggio 2: progettazione Dopo aver raccolto i dati al passaggio 1, è possibile progettare la farm. I risultati sono un'architettura di dati dettagliata e topologie fisiche e logiche.
Determinare l'architettura di partenza
Selezionare i componenti hardware.
Passaggio 3: implementazione dell'ambiente pilota, esecuzione dei test e ottimizzazione Se è stata progettata una nuova distribuzione, è necessario distribuire un ambiente pilota per i test a fronte del carico di lavoro e delle caratteristiche di utilizzo previste. Nel caso di una farm esistente, è consigliabile eseguire i test qualora vengano apportate modifiche importanti all'infrastruttura e sia necessaria una normale ottimizzazione basata sul monitoraggio dei risultati per soddisfare i target definiti per le prestazioni. Il risultato di questa fase è un'analisi dei risultati dei test sulla base dei target e un'architettura ottimizzata in grado di soddisfare i target di prestazioni e capacità stabiliti.
Progetto pilota Distribuire un ambiente pilota.
Eseguire i test Eseguire i test a fronte dei target definiti per latenza e velocità effettiva.
Ottimizzare Raccogliere i risultati dei test e apportare le modifiche necessarie alle risorse e alla topologia della farm.
Passaggio 4: distribuzione Questo passaggio consiste nell'implementazione della farm o nella distribuzione delle modifiche apportate a una farm esistente. Il risultato nel caso di una nuova progettazione consiste in una distribuzione in un ambiente di produzione attivo, incluse tutte le migrazioni di contenuto e utenti. Il risultato nel caso invece di una farm esistente è rappresentato da mappe di farm modificate e aggiornamenti dei piani di manutenzione.
Passaggio 5: monitoraggio e manutenzione Questo passaggio consiste nel monitorare, prevedere e identificare colli di bottiglia, nonché nell'eseguire normali attività di manutenzione e attenuazione dei colli di bottiglia.
Sovradimensionamento e sottodimensionamento
Per sovradimensionamento si intende un metodo di progettazione delle farm in cui i target vengono raggiunti senza sfruttare completamente i componenti hardware e in cui le risorse della farm di SharePoint Server 2013 non vengono utilizzate al massimo delle capacità. In una distribuzione sovradimensionata la memoria, la CPU e altri indicatori delle risorse della farm mostrano che la domanda può essere soddisfatta utilizzando un numero inferiore di risorse. Lo svantaggio di questo metodo è rappresentato da una maggiore spesa in termini di hardware e manutenzione e da maggiori richieste di spazio e risorse energetiche.
Per sottodimensionamento si intende un metodo di progettazione delle farm in cui i target di prestazioni e capacità non sono raggiungibili poiché le risorse hardware della farm di SharePoint Server 2013 sono eccessivamente utilizzate. Il sottodimensionamento di una farm viene applicato a volte per ridurre i costi, ma in genere comporta una latenza elevata con diverse conseguenze negative, tra cui un'esperienza utente inadeguata, un livello di soddisfazione insufficiente, frequenti escalation, costi di assistenza elevati e spese superflue per la risoluzione dei problemi e l'ottimizzazione dell'ambiente.
Quando si progetta la farm, verificare che sia in grado di soddisfare i target di prestazioni e capacità definiti, sia in situazioni di carichi di picco normali sia in casi di sovraccarichi imprevisti. La progettazione, i test e l'ottimizzazione consentiranno di controllare se i componenti hardware della farm sono appropriati.
Per mantenere i target di prestazioni e consentire l'espansione, è sempre consigliabile disporre di più risorse di quelle necessarie per soddisfare i target. Il costo di un investimento in componenti hardware sovradimensionati in genere è meno elevato delle spese cumulative correlate alla risoluzione di problemi causati da un sottodimensionamento.
È consigliabile dimensionare sempre un sistema in modo che risponda adeguatamente in situazioni di picco della domanda, che può variare a seconda dei servizi in momenti diversi. Per una valutazione efficace dei requisiti di capacità, è necessario identificare il momento peggiore in termini di domanda per tutte le risorse. È possibile che si verifichi una situazione di carico maggiore per diverse funzionalità e diversi servizi in alcuni momenti della giornata, ad esempio la mattina o dopo pranzo.
La farm deve inoltre essere in grado di sopportare picchi imprevisti, ad esempio quando vengono effettuati annunci in tutta l'organizzazione e un numero insolitamente alto di utenti accede a un sito nello stesso momento. Durante questi periodi di domanda elevata, gli utenti riscontreranno una latenza superiore oppure non otterranno alcuna risposta dalla farm, a meno che non siano disponibili risorse sufficienti per soddisfare l'aumento di carico nella farm.
La capacità di una farm deve essere modificata con l'ingresso di nuovi utenti nell'azienda. Situazioni quali una fusione o un'acquisizione caratterizzate dall'accesso alla farm da parte di nuovi dipendenti o membri possono produrre effetti negativi sulle prestazioni se non vengono pianificate o calcolate in anticipo.
Stati operativi: area verde e area rossa
Quando si descrive il carico di un sistema di produzione, si fa riferimento a due stati operativi principali: lo stato "area verde", in cui il sistema opera nell'ambito del normale carico previsto, e lo stato "area rossa", in cui nella farm si verifica un aumento elevato e transitorio della richiesta di risorse che può essere supportato solo per periodi di tempo limitati prima che si verifichino errori o altri problemi correlati alle prestazioni e all'affidabilità.
Area verde Questo è lo stato in cui il server o la farm opera in condizioni di carico normali, fino ai carichi di picco giornalieri previsti. Una farm che opera in questo ambito deve essere in grado di offrire tempi di risposta e latenza che rientrano in parametri accettabili.
Area rossa Ambito operativo in cui il carico è maggiore del normale carico di picco, ma è comunque possibile gestire le richieste per un periodo limitato. Questo stato è caratterizzato da una latenza superiore al normale e da possibili errori causati dalla saturazione dei colli di bottiglia del sistema.
L'obiettivo finale della progettazione della farm consiste nel distribuire un ambiente in grado di supportare costantemente uno stato di "area rossa" senza che si verifichino errori dei servizi e con una latenza e una velocità effettiva accettabili.
Limiti software statici e configurabili
In SharePoint Server 2013 sono previsti alcuni limiti che sono configurati da progettazione e che non possono essere superati e altri limiti impostati su valori predefiniti che possono essere modificati dall'amministratore della farm. Vi sono inoltre limiti non rappresentati da un valore configurabile, come ad esempio il numero di raccolte siti per ogni applicazione Web.
I limiti statici sono limiti assoluti che non possono essere superati da progettazione. È importante conoscerli per evitare ipotesi errate durante la progettazione della farm.
Un esempio di limite è il limite di 2 GB di dimensioni del documento. Non è possibile configurare SharePoint Server 2013 per archiviare documenti di dimensioni superiori a 2 GB. Questo è un valore assoluto incorporato che non può essere superato da progettazione.
Le soglie sono quelle con un valore predefinito che non può essere superato a meno che il valore non venga modificato. Le soglie possono, in determinate circostanze, essere superate per contenere le variazioni nella progettazione della farm. Tuttavia, è necessario comprendere che questa operazione potrebbe influire sulle prestazioni della farm e sul valore effettivo di altri limiti.
Il valore predefinito di alcune soglie può essere superato fino a un valore massimo assoluto. Un buon esempio di tale situazione è rappresentato anche in questo caso dal limite di dimensione dei documenti. Per impostazione predefinita, il limite per le dimensioni dei documenti è 50 MB, ma può essere modificato in modo da supportare un valore massimo di 2 GB.
I limiti supportati definiscono il valore testato per un determinato parametro. I valori predefiniti per tali limiti sono stati definiti mediante attività di testing e rappresentano le limitazioni note del prodotto. Il superamento dei limiti supportati può causare risultati imprevisti, un calo significativo delle prestazioni o altri effetti negativi.
Alcuni limiti supportati sono parametri configurabili per cui è specificato per impostazione predefinita il valore consigliato, mentre altri limiti riguardano parametri non rappresentati da un valore configurabile.
Un esempio di limite supportato è il numero di raccolte siti per ogni applicazione Web. Tale limite supportato rappresenta il numero più alto di raccolte siti per applicazione Web che ha soddisfatto i benchmark relativi alle prestazioni durante il testing.
È importante tenere presente che molti dei valori limite riportati in questo documento rappresentano un punto di una curva indicante un carico crescente delle risorse e allo stesso tempo una riduzione delle prestazioni man mano che il valore aumenta. Il superamento di determinati limiti, come ad esempio il numero di raccolte siti per ogni applicazione Web, può pertanto dare luogo a un calo frazionario delle prestazioni della farm. Nella maggior parte dei casi l'utilizzo del sistema in prossimità o al valore limite stabilito non è comunque una procedura consigliata, dal momento che i target di prestazioni e affidabilità accettabili vengono raggiunti in modo ottimale quando una farm viene progettata mantenendo una situazione di equilibro ragionevole relativamente ai valori dei limiti.
Le soglie e i limiti supportati sono determinati dalle prestazioni. In altre parole, è possibile superare i valori predefiniti dei limiti, ma quando si aumenta il valore limite, le prestazioni della farm e il valore effettivo di altri limiti potrebbero essere interessati. È possibile modificare molti limiti in SharePoint Server 2013. Tuttavia, è necessario comprendere in che modo la modifica di un determinato limite influisce su altre parti della farm.
Se si contatta il Servizio Supporto Tecnico Clienti Microsoft per un sistema di produzione che non soddisfa le specifiche hardware minime indicate in Requisiti hardware e software per SharePoint 2013, verrà fornita un'assistenza limitata finché il sistema non verrà aggiornato in modo da possedere i requisiti minimi.
Modalità di definizione dei limiti
In SharePoint Server 2013 le soglie e i limiti supportati vengono stabiliti mediante l'esecuzione di test e l'osservazione del comportamento della farm, la quale viene sottoposta a carichi crescenti fino al raggiungimento dei limiti operativi effettivi da parte dei servizi e delle attività della farm. Alcuni servizi e componenti della farm possono supportare un carico maggiore rispetto ad altri. Pertanto, in alcuni casi, è necessario assegnare un valore limite basato su una media di diversi fattori.
Le osservazioni relative al comportamento della farm sotto carico quando vengono aggiunte raccolte siti indicano ad esempio che alcune funzionalità presentano livelli di latenza eccessivamente elevati mentre altre funzionalità continuano a operare entro parametri accettabili. Il valore massimo assegnato al numero di raccolte siti non è pertanto assoluto, bensì calcolato in base a una serie prevista di caratteristiche di utilizzo in cui le prestazioni globali della farm saranno accettabili al limite dato nella maggior parte delle situazioni.
Se alcuni servizi vengono eseguiti con parametri superiori a quelli utilizzati per il testing dei limiti, si ridurranno i limiti massimi validi per gli altri servizi. È perciò importante eseguire rigorosi esercizi di testing della gestione della capacità e della scalabilità per distribuzioni specifiche per definire i limiti validi per l'ambiente in questione.
Per ulteriori informazioni sui limiti statici e configurabili e su come influiscono sul processo di gestione della capacità, vedere Limiti software statici e configurabili per SharePoint 2013.
Elementi chiave di differenziazione di una distribuzione di SharePoint Server 2013
Ogni distribuzione di SharePoint Server 2013 è univoca e diversa da altre farm grazie a una serie di caratteristiche chiave. Questi elementi chiave di differenziazione sono riconducibili alle quattro categorie principali illustrate di seguito:
Specifica Descrive i componenti hardware, la topologia e la configurazione della farm.
Carico di lavoro Descrive la domanda all'interno della farm, inclusi il numero di utenti e le caratteristiche di utilizzo.
Set di dati Descrive le dimensioni e la distribuzione del contenuto.
Integrità e prestazioni Descrive le prestazioni della farm a fronte dei target di latenza e velocità effettiva.
Specifiche
Hardware
Con il termine hardware si indicano le risorse fisiche del computer, ad esempio i processori, la memoria e i dischi rigidi. Sono inclusi in questa categoria anche i componenti della rete fisica, ad esempio le schede di interfaccia di rete, i cavi, gli switch, i router e il bilanciamento del carico hardware. Molti problemi di prestazioni e capacità possono essere risolti verificando che sia in uso una dotazione hardware appropriata. Una singola applicazione erronea di una risorsa hardware invece, ad esempio la memoria insufficiente in un server, può incidere sulle prestazioni dell'intera farm.
Topologia
Con il termine topologia si indicano la distribuzione e le correlazioni tra le risorse hardware e i componenti di una farm. Esistono due tipi di topologia:
Topologia logica Mappa di componenti software, ad esempio i servizi e le funzionalità di una farm.
Topologia fisica Mappa di server e risorse fisiche.
Il numero di utenti e le caratteristiche di utilizzo in genere determinano la topologia fisica di una farm, mentre i requisiti aziendali, ad esempio la richiesta di supportare funzionalità specifiche per il carico previsto, determinano la topologia logica.
Configurazione
Il termine configurazione viene utilizzato per descrivere le impostazioni software e la modalità di definizione dei parametri. Con questo termine inoltre si fa riferimento alla memorizzazione nella cache, alla struttura RBS, alla modalità di impostazione dei limiti configurabili e a qualsiasi aspetto dell'ambiente software che può essere definito o modificato per soddisfare requisiti specifici.
Carico di lavoro
Il carico di lavoro definisce le caratteristiche operative chiave della farm, inclusi la base di utenti, la concorrenza, le funzionalità in uso e gli agenti utente o le applicazioni client utilizzate per la connessione alla farm.
Funzionalità di SharePoint Server 2013 diverse sono associate a costi diversi per le risorse della farm. La popolarità di funzionalità più costose in termini di utilizzo delle risorse può produrre un impatto potenzialmente significativo sulle prestazioni e sull'integrità del sistema. La conoscenza della domanda prevista e delle caratteristiche di utilizzo consentirà di dimensionare correttamente l'implementazione e di ridurre il rischio di eseguire costantemente il sistema in uno stato non integro.
Base di utenti
Per base di utenti di un'applicazione basata su SharePoint Server 2013 si intende una combinazione del numero totale di utenti e della relativa distribuzione geografica. Nell'ambito della base di utenti totale esistono inoltre sottogruppi di utenti che possono utilizzare determinate funzionalità o servizi con maggiore intensità rispetto ad altri gruppi. La concorrenza di utenti è definita come la percentuale totale di utenti che utilizzano il sistema in un determinato momento. Tra gli indicatori che definiscono la base di utenti sono inclusi il numero totale di utenti univoci e il numero di utenti simultanei.
Caratteristiche di utilizzo
Le prestazioni di una farm possono essere determinate non solo dal numero di utenti che interagiscono con il sistema, ma anche dalle relative caratteristiche di utilizzo. In due organizzazioni con lo stesso numero di utenti possono esservi requisiti significativamente diversi in base alla frequenza con cui gli utenti accedono alle risorse della farm e a seconda che nella farm siano abilitati funzionalità e servizi a elevato utilizzo di risorse. Gli indicatori che descrivono le caratteristiche di utilizzo includono la frequenza delle operazioni univoche, la combinazione operativa complessiva (il rapporto tra operazioni di lettura e scrittura e operazioni amministrative) e i modelli di utilizzo e il carico rispetto alle nuove funzionalità abilitate nella farm ,ad esempio Siti personali, Ricerca, Flussi di lavoro e Office Online Server.
Set di dati
Il volume del contenuto archiviato nel sistema e le caratteristiche dell'architettura in cui è archiviato possono produrre un effetto significativo sull'integrità e le prestazioni globali del sistema. La conoscenza delle dimensioni, della frequenza di accesso e della distribuzione dei dati consentirà di dimensionare correttamente lo spazio di archiviazione del sistema ed evitare la formazione di colli di bottiglia, che altrimenti possono rallentare le interazioni degli utenti con i servizi della farm e produrre un effetto negativo sull'esperienza degli utenti finali.
Per calcolare e progettare correttamente l'architettura dello spazio di archiviazione di una soluzione basata su SharePoint Server 2013, è necessario conoscere il volume di dati che verranno archiviati nel sistema e il numero di utenti che richiedono dati da origini dati diverse. Il volume del contenuto è un elemento importante per dimensionare la capacità dei dischi, poiché può influire sulle prestazioni di altre funzionalità e può incidere inoltre sulla latenza di rete e sulla larghezza di banda disponibile. Tra gli indicatori che definiscono il set di dati sono inclusi le dimensioni totali del contenuto, il numero totale di documenti, il numero totale di raccolte siti e le dimensioni medie e massime delle raccolte siti.
Integrità e prestazioni
L'integrità di una farm di SharePoint Server 2013 è fondamentalmente una misura semplificata che riflette l'affidabilità, la stabilità e le prestazioni del sistema. Il livello delle prestazioni della farm a fronte dei target dipende principalmente dai primi tre elementi di differenziazione. Lo stato di integrità e prestazioni può essere monitorato e descritto da una combinazione di un insieme di indicatori. Per ulteriori informazioni, vedere Monitoraggio e manutenzione di SharePoint Server 2013 e Pianificare il monitoraggio in SharePoint Server. Tali indicatori includono il tempo di attività del sistema, la latenza percepita dagli utenti finali, la frequenza di errori delle pagine e gli indicatori di utilizzo delle risorse (CPU, RAM).
Qualsiasi modifica significativa apportata alle risorse hardware, alla topologia, alla configurazione, al carico di lavoro o al set di dati può determinare una variazione in termini di affidabilità e tempi di risposta del sistema. Lo stato di integrità può essere utilizzato per tenere traccia delle prestazioni nel tempo e per valutare l'impatto prodotto da condizioni operative variabili o da modifiche del sistema sull'affidabilità della farm.
Architetture di riferimento
SharePoint Server 2013 è un prodotto complesso e potente e non esiste un'unica soluzione di architettura valida per tutte le condizioni. Ogni distribuzione di SharePoint Server 2013 è univoca ed è definita da caratteristiche di utilizzo e dati specifiche. In ogni organizzazione deve essere eseguito un processo accurato di gestione della capacità e deve essere sfruttata al massimo la flessibilità offerta dal sistema SharePoint Server 2013, in modo da creare una soluzione personalizzata correttamente dimensionata per soddisfare al meglio le esigenze organizzative.
Il concetto di architetture di riferimento è progettato per descrivere e illustrare le diverse categorie principali delle distribuzioni di SharePoint Server 2013 e non per fornire agli architetti una ricetta da usare per progettare le proprie soluzioni. Questa sezione descrive i vettori su cui vengono in genere ridimensionate le distribuzioni di SharePoint Server 2013.
Le architetture descritte in questa sezione sono utili per conoscere gli elementi generali di differenziazione tra queste categorie generiche e per differenziarle in base a fattori di costo e impegno richiesto.
Distribuzione a server singolo
L'architettura della distribuzione a server singolo è costituita da un server che esegue SharePoint Server 2013 e una versione supportata di SQL Server. Questa architettura può essere appropriata a scopo di valutazione, per sviluppatori oppure per un'implementazione di reparto isolata non cruciale con pochi utenti. Non è consigliabile tuttavia utilizzarla per un ambiente di produzione.
Distribuzione di farm di piccole dimensioni
Una distribuzione di farm di piccole dimensioni è costituita da un singolo server di database o da un cluster e da uno o due computer basati su SharePoint Server 2013. Tra le caratteristiche principali dell'architettura sono inclusi ridondanza e failover limitati, nonché un set minimo di funzionalità di SharePoint Server 2013 abilitate.
Una farm di piccole dimensioni è utile per la gestione solo di distribuzioni limitate, con un insieme ridotto di applicazioni di servizio abilitate e una base di utenti relativamente piccola, un carico di utilizzo relativamente ridotto (da poche richieste al minuto a poche richieste al secondo) e un volume relativamente ridotto di dati (10 o più gigabyte).
Distribuzione di farm di medie dimensioni
Con questa architettura viene introdotta la suddivisione della topologia in tre livelli: server Web dedicati, server applicazioni dedicati e uno o più server di database o cluster. La separazione del livello dei server front-end dal livello dei server applicazioni garantisce una maggiore flessibilità per l'isolamento dei servizi e consente di bilanciare il carico nel sistema.
Questa è l'architettura più comune e include una vasta gamma di topologie di servizi e dimensioni di farm. Una distribuzione di farm di medie dimensioni è utile per la gestione di ambienti con le caratteristiche seguenti:
Diverse applicazioni di servizio distribuite in più server. Un insieme tipico di funzionalità può includere ad esempio il servizio Office Online, il servizio profili utente, il servizio metadati gestiti e Servizi di calcolo Excel.
Una base di utenti di decine di migliaia di utenti e un carico di 10-50 richieste al secondo.
Un archivio dati di uno o due terabyte.
Distribuzione di farm di grandi dimensioni
Con questa architettura viene introdotta la distribuzione di servizi e soluzioni in più farm, nonché scalabilità orizzontale aggiuntiva dei livelli di una singola farm. È possibile distribuire diversi servizi di SharePoint Server 2013 in una farm di servizi dedicati che gestisce le richieste di più farm di utilizzo. In queste architetture estese sono inclusi in genere server Web, più server applicazioni, a seconda delle caratteristiche di utilizzo di ognuno dei servizi locali (non condivisi), e più server basati su SQL Server o cluster SQL Server, a seconda delle dimensioni del contenuto e dei database dei servizi per le applicazioni abilitati nella farm. Le architetture di farm di grandi dimensioni vengono utilizzate in genere per gestire distribuzioni con le caratteristiche seguenti:
Diverse applicazioni di servizio federate e utilizzate da farm di servizi dedicati, generalmente il servizio profili utente, il servizio di ricerca, il servizio metadati gestiti e Web Analytics.
La maggior parte delle altre applicazioni di servizio abilitate localmente.
Una base di utenti di centinaia di migliaia di utenti.
Un carico di utilizzo di centinaia di richieste al secondo.
Un set di dati di un minimo di 10 terabyte.
Vedere anche
Concetti
Pianificazione della capacità per SharePoint Server 2013
Esecuzione dei test delle prestazioni di SharePoint Server 2013
Monitoraggio e manutenzione di SharePoint Server 2013
Pianificare il monitoraggio in SharePoint Server
Risultati dei testi delle prestazioni e della capacità e suggerimenti (SharePoint Server 2013)
Ulteriori risorse
Limiti software statici e configurabili per SharePoint 2013
Requisiti hardware e software per SharePoint 2013
Case study tecnici su prestazioni e capacità (SharePoint Server 2010)