1. Effetti di RBS sulla dimensione del database di SQL

Prestazioni di SQL Server RBS con SharePoint
Server 2010 e la soluzione di archiviazione
StorSimple
Questo documento viene fornito “così com’è”. Le informazioni e le opinioni espresse nel presente
documento, inclusi gli URL e altri riferimenti a siti Web Internet, possono essere soggette a modifiche senza
preavviso. L’utente accetta di utilizzarlo a proprio rischio.
Il presente documento non implica la concessione di alcun diritto di proprietà intellettuale relativo ai prodotti
Microsoft. È possibile copiare e utilizzare questo documento per fini di riferimento interno. Non è possibile
modificare questo documento per fini personali o di riferimento.
© 2011 Microsoft Corporation. Tutti i diritti riservati.

Microsoft SharePoint Server 2010
Aprile 2011
Prestazioni di SQL Server RBS con SharePoint
Server 2010 e la soluzione di archiviazione
StorSimple
Burzin Patel
StorSimple, Inc.
Peter Scharlock
Microsoft Corporation
Revisori tecnici: John Flores (StorSimple, Inc.), Srini Acharya, Steve Howard, Shaun Tinline-Jones, Mike
Weiner, Kun Cheng, Prem Mehra, Jimmy May, David Koronthaly, Bill Baer
Dicembre 2010. Revisione: aprile 2011
Si applica a:
SharePoint Server 2010 e SQL Server 2008 R2
Riepilogo: in anni recenti l’utilizzo della tecnologia Microsoft® SharePoint® ha subito un’espansione
imponente. Questa espansione è stata prodotta dall’elevata quantità di documenti, nonché di documenti
multimediali di dimensioni maggiori, archiviati dagli utenti in raccolte di SharePoint, che a loro volta hanno
generato un aumento dei costi di archiviazione e alcune importanti sfide in termini di prestazioni e
gestibilità per gli amministratori di SharePoint. Microsoft ha affrontato questi problemi introducendo
supporto tecnico nativo per la caratteristica Archiviazione BLOB remoti (RBS) di SharePoint Server 2010. In
questo documento viene descritta la caratteristica RBS in relazione a SharePoint Server 2010,
esaminandone l’impatto per le prestazioni sui principali attributi di una farm di SharePoint, quali
dimensione del database, dimensioni dei backup dei database, tempi di risposta delle transazioni e tempi di
backup e ripristino.
© 2011 Microsoft Corporation. Tutti i diritti riservati.
Pagina 2
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs ([email protected]).
Microsoft SharePoint Server 2010
Aprile 2011
Sommario
Introduzione ......................................................................................................................................................4
Archiviazione BLOB remoti ..................................................................................................................................4
Perché utilizzare RBS ....................................................................................................................................5
Obiettivi dei test ................................................................................................................................................6
Metodologia dei test ...........................................................................................................................................7
Carico di lavoro............................................................................................................................................7
Configurazione del server..............................................................................................................................9
Configurazione hardware ........................................................................................................................9
Configurazione dell’archiviazione ........................................................................................................... 10
Configurazione software ....................................................................................................................... 10
Risultati dei test e osservazioni .......................................................................................................................... 11
1. Effetti di RBS sulla dimensione del database di SQL Server .......................................................................... 11
2. Effetti di RBS sulle dimensioni dei backup dei database ............................................................................... 13
3. Effetti di RBS sui tempi di backup e ripristino ............................................................................................. 16
4. Effetti di RBS sulle prestazioni di ricostruzione degli indici ........................................................................... 18
5. Effetti di RBS sui tempi di risposta delle transazioni di SharePoint ................................................................ 20
6. Effetti di RBS sulle prestazioni della ricerca per indicizzazione ...................................................................... 22
7. Effetti di RBS sulle prestazioni di caricamento dei file .................................................................................. 23
8. Tempo necessario per la migrazione dei dati .............................................................................................. 25
Conclusioni ...................................................................................................................................................... 26
Risorse aggiuntive ............................................................................................................................................ 27
Informazioni su StorSimple ............................................................................................................................... 27
Informazioni su Microsoft .................................................................................................................................. 27
© 2011 Microsoft Corporation. Tutti i diritti riservati.
Pagina 3
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs ([email protected]).
Microsoft SharePoint Server 2010
Aprile 2011
Introduzione
La popolarità di Microsoft SharePoint Server è cresciuta in misura esponenziale negli ultimi anni. Questa crescita
si è verificata grazie all’adozione di SharePoint Server da parte di più clienti, nonché all’archiviazione da parte
di un numero sempre maggiore di utenti di documenti e set di dati di dimensioni superiori in farm di SharePoint.
Con la recente versione di SharePoint Server 2010, è prevista una crescita ancora maggiore.
SharePoint Server 2010 presenta un’interfaccia utente semplificata in grado di offrire un’esperienza
utente ottimale, che rende SharePoint Server l’archivio ideale per tutti i tipi di dati. Questi aspetti,
insieme all’aumento di contenuti multimediali avanzati, producono l’espansione delle dimensioni del
contenuto della farm di SharePoint, che a sua volta provoca un aumento significativo della capacità di
archiviazione fisica necessaria. Questo aumento di dimensioni pone spesso una sfida agli amministratori di
SharePoint, che devono affrontare il carico di lavoro aggiuntivo correlato alla gestione di più contenuto,
database più grandi e backup sempre maggiori. Per affrontare questo scenario, in SharePoint Server 2010
è stata introdotta una nuova caratteristica, Archiviazione BLOB remoti (RBS), che consente di risolvere i
problemi generati dall’espansione del contenuto di SharePoint.
In questo documento vengono illustrati i vantaggi e le caratteristiche di funzionamento di RBS, quando
questo viene utilizzato insieme a Microsoft SharePoint Server 2010, nonché le caratteristiche correlate alle
prestazioni di una farm di SharePoint configurata per l’esecuzione con la soluzione di archiviazione
StorSimple, come verrà descritto nella prossima sezione. Vantaggi quali la riduzione delle dimensioni del
database, backup e ripristini di database più veloci, migliori tempi di risposta per documenti di dimensioni
maggiori, migliore manutenzione dei database e minore richiesta sull’archivio back-end, verranno trattati
insieme alle coordinate relative alla prestazioni. Tutte le coordinate presentate nel documento sono state
generate come parte dei test delle prestazioni svolti presso i laboratori di StorSimple, Inc. a Santa Clara
insieme ai team di prodotto di Microsoft SQL Server e SharePoint.
Nota: i risultati dei test inclusi in questo white paper sono specifici degli ambienti descritti
nel white paper stesso. I risultati possono variare.
Archiviazione BLOB remoti
BLOB è l’acronimo di Binary Large Object e nel contesto delle applicazioni di SharePoint si riferisce
all’oggetto file archiviato nel database. Archiviazione BLOB remoti (RBS) è un set di API delle raccolte di
Microsoft® SQL Server® integrato come Feature Pack aggiuntivo per Microsoft SQL Server 2008 R2. La
caratteristica RBS consente alle applicazioni di archiviare oggetti BLOB esternamente al database, ad
esempio in una condivisione di file, per ridurre la capacità di archiviazione del database di SQL Server
necessaria. Un archivio RBS è in genere un volume distinto nella stessa rete di SQL Server. SharePoint
Server 2010 utilizza la caratteristica RBS per archiviare esternamente gli oggetti BLOB archiviati nel
database del contenuto. SQL Server e SharePoint Server gestiscono insieme l’integrità dei dati tra i record
del database e l’archivio esterno RBS per ciascun database.
Per la caratteristica RBS di SQL Server è necessario che sia installato un provider in ogni server front-end
Web SharePoint in cui è configurata l’applicazione SharePoint. Il provider include un set di DLL per
l’implementazione di metodi per le API di RBS e per l’esecuzione dell’effettiva operazione di archiviazione
esterna degli oggetti BLOB.
Per tutti i test svolti e descritti in questo documento, è stata configurata nella farm di SharePoint Server
2010 l’utilità StorSimple di ottimizzazione del database di SharePoint (StorSimple SharePoint Database
Optimizer), che include un provider RBS. La configurazione è stata eseguita utilizzando lo strumento di
© 2011 Microsoft Corporation. Tutti i diritti riservati.
Pagina 4
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs ([email protected]).
Microsoft SharePoint Server 2010
Aprile 2011
gestione della configurazione RBS dell’utilità StorSimple di ottimizzazione del database di SharePoint,
un’estensione del sito Amministrazione centrale, illustrata nella figura (i) di seguito.
Figura (i) - Utilità StorSimple di ottimizzazione del database di SharePoint - Configurazione di RBS
Perché utilizzare RBS
Tutti i dati di SharePoint Server vengono archiviati nel database. Con l’aumentare del contenuto archiviato, la
dimensione del database può crescere molto rapidamente. Questa crescita è imputabile al caricamento di nuovo
contenuto in SharePoint Server, nonché a revisioni di contenuto esistente quando è abilitato il controllo delle
versioni di SharePoint. In questo caso, anche se viene modificato un solo byte di un documento di SharePoint,
nel database viene archiviata una nuova copia dell’intero oggetto BLOB e la vecchia copia viene contrassegnata
come versione precedente. Come molti amministratori di SharePoint hanno già notato, questo comportamento
produce un aumento esponenziale delle dimensioni del contenuto.
Con l’aumentare della dimensione del database, diventa sempre più difficile gestire il sistema e garantire
prestazioni ottimali. Attività altrimenti essenziali come backup e ripristino e deframmentazione del
database diventano sempre più impegnative da eseguire. Questo è uno dei motivi per cui Microsoft
consiglia agli utenti di limitare le dimensioni dei database perché siano gestibili, come descritto in questo
articolo: “Gestione della capacità di SharePoint Server 2010: limiti software statici e configurabili”
(http://technet.microsoft.com/it-it/library/cc262787.aspx#ContentDB). L’adozione di questa procedura
consigliata può imporre a un amministratore di SharePoint la necessità di creare più database, che
comporta un aumento dei costi in termini di gestione e manutenzione. Un numero maggiore di database
produce più backup da gestire e monitorare, che a loro volta implicano più amministratori di SharePoint.
© 2011 Microsoft Corporation. Tutti i diritti riservati.
Pagina 5
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs ([email protected]).
Microsoft SharePoint Server 2010
Aprile 2011
Se si utilizza RBS, l’applicazione può archiviare grandi quantità di dati non strutturati come video multimediali o
file audio avanzati, sfruttando il meglio delle funzionalità relazionali di SQL Server e la scalabilità di un archivio
BLOB del file system di Windows®. Oltre a questo importante vantaggio, la caratteristica RBS ne offre molti altri
correlati a costi di archiviazione, manutenzione, prestazioni e flessibilità:

Database di dimensioni minori, per un uso ottimale delle costose risorse del server di database come
processori, memoria e dischi

File di backup di database di dimensioni minori

Tempi di backup e ripristino più rapidi

Operazioni di manutenzione del database, come deframmentazione e ricostruzione degli indici, più rapide

Migliori prestazioni complessive, in particolare per l’accesso a oggetti di grandi dimensioni e la loro
archiviazione.
Quando SharePoint Server è configurato per l’utilizzo di RBS, la semantica di transazione delle operazioni
utente viene preservata completamente e non si osserva assolutamente alcuna modifica da un punto di
vista dell’utente finale. L’attività di archiviazione degli oggetti BLOB esternamente al database viene
eseguita automaticamente nel back-end da SharePoint Server insieme al provider RBS. Benché RBS
funzioni correttamente se utilizzato con il clustering di failover di SQL Server, non funziona con il mirroring
di SQL Server quando viene eseguito il mirroring del database del contenuto di SharePoint in un server di
database che si trova in un’altra farm.
Obiettivi dei test
L’obiettivo del testing è stato quello di definire le prestazioni di una farm di SharePoint configurata con RBS
tramite il provider RBS di StorSimple, che fa parte dell’utilità StorSimple di ottimizzazione del database di
SharePoint, e quindi di confrontarle con quelle di una farm di SharePoint senza la caratteristica RBS
abilitata. Si è inoltre voluto misurare gli effetti di RBS sugli elementi seguenti:

Dimensioni dei dati del database e dei file di registro delle transazioni di SQL Server

Dimensioni dei file di backup

Tempo impiegato per il backup e il ripristino del database del contenuto

Tempo impiegato per la ricostruzione degli indici del database del contenuto

Effetti dell’operazione di ricostruzione degli indici sulle prestazioni delle transazioni degli utenti finali

Tempi di risposta delle transazioni di SharePoint

Operazione di ricerca per indicizzazione di SharePoint Server

Prestazioni di caricamento dei file

Coerenza delle prestazioni con l’aumentare delle dimensioni del contenuto

Tempo impiegato per la migrazione di dati da e verso l’archivio RBS
Il comportamento di SharePoint Server 2010 per diverse caratteristiche del carico di lavoro delle
applicazioni o per soglie diverse per le dimensioni degli oggetti BLOB archiviati esternamente non è incluso
nella trattazione di questo documento.
© 2011 Microsoft Corporation. Tutti i diritti riservati.
Pagina 6
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs ([email protected]).
Microsoft SharePoint Server 2010
Aprile 2011
Metodologia dei test
Come obiettivo, si è voluto condurre i test descritti nella sezione precedente su un carico di lavoro che
rappresentasse scenari quanto più reali possibile. Un altro obiettivo è stato il mantenimento della
configurazione per i test (configurazione del server, impostazioni del database, schema della tabella e così
via) relativamente costante in tutti i test, in modo da poter identificare analogie e differenze tra le
prestazioni delle diverse operazioni.
I test sono stati suddivisi in tre ampie categorie: (1) test di caricamento, (2) test sulla combinazione
completa delle transazioni e (3) test vari.
Test di caricamento di documenti: tramite questo insieme di test sono stati misurati prestazioni ed
effetti di RBS sul caricamento di documenti degli utenti per diverse dimensioni di file medie.
Test sulla combinazione completa di transazioni di SharePoint: tramite questo insieme di test sono
stati misurati gli effetti di RBS sulle prestazioni della farm di SharePoint. I test hanno incluso tutte le
transazioni utente di SharePoint comunemente eseguite, quali selezione, ricerca, caricamento di documenti
e creazione di siti. Il principale criterio di valutazione delle prestazioni utilizzato è stato il tempo medio di
risposta delle pagine Web.
Test vari: questi test hanno incluso operazioni come il backup e il ripristino del database, la migrazione di
oggetti da e verso il database e nell’archivio RBS e la ricerca per indicizzazione di SharePoint Server.
Carico di lavoro
Le diverse domande a cui hanno dovuto rispondere i test hanno comportato l’utilizzo di set di dati di carichi
di lavoro diversi. Per i test sono stati utilizzati due carichi di lavoro: (1) la combinazione di carichi di lavoro
per il caricamento di file e (2) la combinazione completa di transazioni di SharePoint.
La combinazione di carichi di lavoro per il caricamento di file ha incluso due set di file con dimensioni
pesate medie di circa 100 KB, utilizzate per generare il database di 100 GB, e di 500 KB, utilizzate per
generare il database del contenuto di 1 TB. La distribuzione delle dimensioni dei file per il set di dati di 100
KB è illustrata nella figura (ii).
Figura (ii) - Distribuzione delle dimensioni dei file dei carichi di lavoro
© 2011 Microsoft Corporation. Tutti i diritti riservati.
Pagina 7
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs ([email protected]).
Microsoft SharePoint Server 2010
Aprile 2011
La combinazione di carichi di lavoro per il caricamento di file è stata utilizzata innanzitutto per misurare le
caratteristiche di caricamento dei documenti con e senza RBS.
La combinazione completa di transazioni di SharePoint è stata utilizzata per rappresentare una
combinazione di transazioni di SharePoint tipiche eseguite giornalmente da un utente finale. È stato
utilizzato Microsoft Visual Studio® Team System 2008 Team Suite per generare il carico di lavoro tramite
una versione modificata del toolkit di Microsoft Office SharePoint Server 2007 originale condiviso in
Codeplex. Per ciascun test sono state utilizzate le transazioni seguenti.
Test
Descrizione
Percentuale
Flusso di lavoro pagine
Eseguire un flusso di lavoro di pagine: estrazione, approvazione e
archiviazione
1%
Creazione di una
pagina
Creare una nuova pagina
6%
Strumento di gestione
del sito
Aprire la visualizzazione dello strumento di gestione del sito
1%
Creazione di un sito di
pubblicazione
Creare un nuovo sito con il modello di pubblicazione
1%
Creazione di un sito
del team
Creare una nuova raccolta siti utilizzando il modello di sito del team
incluso nella directory dei siti
1%
Home page
Accedere alla home page del portale
25%
Pagina grande
Accedere a un’ampia gamma di pagine nel portale
10%
Pagina pubblica Sito
personale
Accedere alla pagina pubblica Sito personale
16%
Modifica del profilo del
sito personale
Modificare il profilo personale
7%
Query di ricerca
Eseguire una query di ricerca e visualizzare i risultati nella pagina
Centro ricerche
15%
Caricamento di un
documento
Caricare un documento (in media di 90 KB)
5%
Download di un
documento
Scaricare un documento (in media di 90 KB)
12%
Totale:
100%
Tabella (i) - Combinazione completa di transazioni di SharePoint
© 2011 Microsoft Corporation. Tutti i diritti riservati.
Pagina 8
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs ([email protected]).
Microsoft SharePoint Server 2010
Aprile 2011
Configurazione del server
La farm di SharePoint è stata configurata con sei server front-end Web, un server applicazioni impostato
per l’esecuzione del crawler di ricerca e un server di database, come illustrato nella figura (iii).
Figura (iii) - Topologia della farm di SharePoint
Il server front-end Web e il server applicazioni sono stati configurati per l’esecuzione in una macchina
virtuale, mentre il server di database è stato eseguito in un server fisico dedicato (non virtualizzato).
Sono stati inoltre utilizzati sei server driver di carico basati su macchine virtuali (non illustrati nella figura)
per generare il
carico di lavoro per la combinazione di transazioni di caricamento dei file e la combinazione completa di
transazioni di SharePoint.
Configurazione hardware
Ruolo del computer
Hardware
Front-end Web
2 processori Intel Xeon E5504 a processore doppio da 2 GHz (virtualizzati)
8 GB di RAM
Server applicazioni
2 processori Intel Xeon a processore doppio da 2 GHz (virtualizzati)
8 GB di RAM
Server di database
2 processori Intel Xeon da 2 GHz quad-core (virtualizzati)
16 GB di RAM (12 GB assegnati a SQL Server)
Tabella (ii) - Configurazione hardware
© 2011 Microsoft Corporation. Tutti i diritti riservati.
Pagina 9
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs ([email protected]).
Microsoft SharePoint Server 2010
Aprile 2011
Configurazione dell’archiviazione
L’archiviazione utilizzata nel test benchmark è stata configurata nel dispositivo di archiviazione
StorSimple 10101. I database di sistema di SQL Server, i database di SharePoint e l’archivio BLOB sono
stati posizionati in volumi distinti, come illustrato nella tabella (iii) seguente.
Volume
Unità
Database di sistema SQL
C:\
Dati e file di registro di tempdb
H:\
File di dati del database del contenuto
P:\
File di registro del database del contenuto
Q:\
File di dati del database di ricerca
S:\
File di registro del database di ricerca
Q:\
Archivio BLOB
X:\
Copie di backup
O:\
Tabella (ii) - Configurazione dell’archiviazione
Configurazione software
Le versioni e le impostazioni software utilizzate per i diversi server sono indicate nella tabella (iv) seguente.
Software
Modifiche aggiuntive
Ruolo del
computer
Server
applicazioni e
front-end Web
Windows Server® 2008 R2
Enterprise x64
Sono state applicate tutte le patch più
recenti di Windows Server.
Microsoft SharePoint Server 2010
RBS.msi è stato installato da SQL
Server 2008 R2 Feature Pack.
Server di
database
Windows Server 2008 R2 Enterprise
x64
SQL Server 2008 R2 Enterprise x64
Sono state applicate tutte le patch più
recenti di Windows Server.
Sono state apportate le modifiche
seguenti alle impostazioni del server di
database:
-
‘Max Server Memory’ = 12 GB
-
Sono stati creati 4 file di dati tempdb,
spostati nel rispettivo volume.
Tabella (iv) - Configurazione software
1
StorSimple 1010 è un dispositivo di archiviazione ottimizzato per applicazioni come Microsoft SharePoint e Microsoft
Exchange. Per ulteriori informazioni, visitare il sito Web all’indirizzo http://www.storsimple.com.
© 2011 Microsoft Corporation. Tutti i diritti riservati.
Pagina 10
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs ([email protected]).
Microsoft SharePoint Server 2010
Aprile 2011
Risultati dei test e osservazioni
Questa sezione contiene un riepilogo dei risultati dei test svolti per misurare gli effetti dell’utilizzo di RBS
per archiviare esternamente il contenuto degli oggetti BLOB sui diversi attributi di una distribuzione di
SharePoint Server 2010 e rispondere alle domande elencate nella tabella (v) seguente.
Descrizione test
1
Effetti di RBS sulla dimensione del database
2
Effetti di RBS sulle dimensioni dei backup dei database
3
Effetti di RBS sui tempi di backup e ripristino
4
Effetti di RBS sulle prestazioni di ricostruzione degli indici
5
Effetti di RBS sui tempi di risposta delle transazioni di SharePoint
6
Effetti di RBS sull’operazione di ricerca per indicizzazione
7
Effetti di RBS sul caricamento di file per diverse dimensioni di file
8
Tempo impiegato per la migrazione di dati da e verso l’archivio RBS
Tabella (v) - Scenari di test
1. Effetti di RBS sulla dimensione del database
di SQL Server
Come illustrato nella sezione dedicata a RBS, la maggior parte dei dati inclusi nel database di SQL Server
corrisponde a dati BLOB di SharePoint. Nella maggior parte delle distribuzioni di SharePoint, in particolare quelle
in cui SharePoint è utilizzato per la gestione della collaborazione e dei record, i dati BLOB occupano oltre il 95%
della dimensione del database. A seconda della dimensione del database, questo contenuto può essere
facilmente tradotto in centinaia di gigabyte di dati del database. Benché si tratti di una caratteristica propria
della progettazione, pone diversi problemi e costituisce spesso un fattore limitante all’utilizzo di SharePoint
Server, alla scalabilità della soluzione e all’utilizzo di alcune caratteristiche utili come i Cestini.
In questi test, i cui risultati vengono riassunti in questa sezione, sono state misurate le dimensioni di database,
file di dati e file di registro delle transazioni per database del contenuto di SharePoint di 100 GB contenenti
100.000 oggetti e un database del contenuto di SharePoint di 1 TB contenente 2 milioni di oggetti con e senza
la caratteristica RBS. Le dimensioni dei file per ognuno dei database sono indicate nella tabella (vi).
Dimensioni (GB)
Riduzione
Senza RBS
Con RBS
Dimensione dei database (100 GB)
217,2
7,0
96,8%
Dimensioni dei file di dati del database (100 GB)
106,9
3,2
97,0%
Dimensioni dei file di registro delle transazioni
dei database (100 GB)
111,6
3,8
96,6%
--
96,2
--
2.292
26
98,9%
Dimensioni dei dati RBS archiviati esternamente
Dimensione del database (1 TB)
© 2011 Microsoft Corporation. Tutti i diritti riservati.
Pagina 11
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs ([email protected]).
Microsoft SharePoint Server 2010
Aprile 2011
Dimensioni dei file di dati del database (1 TB)
1.120
6,5
99,4%
Dimensioni dei file di registro delle transazioni
del database (1 TB)
1.173
20
98,3%
--
1.115
--
Dimensioni dei dati RBS archiviati esternamente
Tabella (vi) - Dimensioni di database e file
Figura (iv) - Dimensioni di database e file
Come illustrato nella figura (iv) precedente, senza RBS le dimensioni complessive dei database dopo il
caricamento di contenuto di SharePoint di 100 GB e 1 TB sono passate rispettivamente a 217,2 GB e 2,29
TB. Per il database con 100 GB di contenuto di SharePoint, 106,9 GB corrispondono agli effettivi dati del
database, mentre gli altri 111,6 GB corrispondono al registro delle transazioni del database. Analogamente,
per il database con 1 TB di contenuto di SharePoint, 1,12 TB corrispondono al database e 1,2 TB
corrispondono al registro delle transazioni del database. Per un database con RBS abilitato, la dimensione
del database del contenuto di 100 GB è minore del 96,8%, mentre la dimensione del database del
contenuto di 1 TB è minore del 98,9%. Le dimensioni dei dati e dei file di registro delle transazioni sono
minori in misura corrispondente.
Mentre lo spazio aggiuntivo necessario per l’archiviazione di oggetti BLOB nel database è in genere
evidente e noto, un aspetto negativo meno noto e ancor meno compreso è in genere correlato all’aumento
dei file di registro delle transazioni di SQL Server. Il motivo di tale aumento è che SQL Server è un
database coerente dal punto di vista delle transazioni e offre proprietà ACID. Ciò significa che ogni
transazione avrà sicuramente esito positivo o negativo, senza alcuno stato intermedio. SQL Server
implementa le proprietà ACID tramite la registrazione completa di ogni operazione nel registro delle
transazioni del database utilizzando accesso al disco write-through prima del commit dell’operazione. Le
proprietà ACID si applicano a tutti i dati e i tipi di dati di SQL Server, inclusi gli oggetti BLOB. Non esiste
alcun meccanismo per disabilitare o aggirare questo comportamento in alcun modo. Come prevedibile,
© 2011 Microsoft Corporation. Tutti i diritti riservati.
Pagina 12
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs ([email protected]).
Microsoft SharePoint Server 2010
Aprile 2011
quando gli oggetti BLOB di SharePoint vengono archiviati nel database di SQL Server, vengono scritti due
volte, la prima nel registro delle transazioni e la seconda nel file di database, come si può notare dalla
dimensione del database (2,29 TB) utilizzato per l’archiviazione di 1 TB di contenuto utente. Questo file di
registro viene troncato quando si esegue il backup del database e si seleziona l’opzione Tronca log.
Quando si utilizza RBS per archiviare esternamente il contenuto BLOB, i dati BLOB vengono scritti nell’archivio
BLOB prima del commit dell’operazione di SharePoint. Le proprietà ACID dell’operazione vengono pertanto
realizzate indirettamente senza incorrere negli overhead doppi di scrittura del registro della transazioni. La
percentuale di riduzione nei dati e nei file di registro delle transazioni del database dipende dalle dimensioni dei
dati e dalla frequenza con cui si tronca il registro delle transazioni durante un backup.
Il contenuto BLOB spostato esternamente viene archiviato in una condivisione di file centralizzata cui
possono accedere tutti i server applicazioni e front-end Web. Il volume di questa condivisione di file si
trova nel server di database o in un altro server. Nella figura (v) vengono illustrate le proprietà della
condivisione di file utilizzata nei test benchmark.
Figura (v) - Dimensione del volume della condivisione di file RBS
Nota: poiché RBS riduce la dimensione del database tramite lo spostamento dei dati BLOB a un archivio
esterno, è importante tenere presente che non viene ridotto lo spazio su disco complessivo utilizzato dai
dati BLOB. I fornitori di archiviazione possono naturalmente fornire supporto tramite tecnologie proprietarie
quali la deduplicazione, che consente di ridurre lo spazio su disco. Gli oggetti BLOB non vengono
automaticamente eliminati dall’archivio RBS quando il contenuto corrispondente viene eliminato da
SharePoint, ma è necessario un ciclo di Garbage Collection distinto tramite il processo di manutenzione
RBS predefinito per eliminare gli oggetti BLOB orfani.
2. Effetti di RBS sulle dimensioni dei backup dei
database
In questi test, i cui risultati vengono riassunti in questa sezione, sono stati misurati gli effetti di RBS sulle
dimensioni dei backup dei database per un database del contenuto di SharePoint di 100 GB costituito da
© 2011 Microsoft Corporation. Tutti i diritti riservati.
Pagina 13
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs ([email protected]).
Microsoft SharePoint Server 2010
Aprile 2011
100.000 oggetti e per un database del contenuto di SharePoint di 1 TB costituito da 2 milioni di oggetti. I test e
l’analisi non hanno incluso l’archivio RBS. Di conseguenza, le tecniche e le durate correlate al backup e al
ripristino dei dati BLOB contenuti nell’archivio RBS sono escluse dalla trattazione di questo white paper.
Per eseguire il backup è stato utilizzato il comando Transact-SQL seguente.
BACKUP DATABASE [WSS_Content] TO DISK = N’O:\WSS_Content’ WITH NOFORMAT, INIT,
’WSS_Content-Full Database Backup’, SKIP, NOREWIND, NOUNLOAD;
NAME = N
Sono stati svolti inoltre test per misurare gli effetti della caratteristica di compressione dei backup di SQL
Server2 per determinarne gli effetti sulle dimensioni del backup con e senza RBS. Nella tabella (vii)
seguente viene presentato un riepilogo dei risultati dei test.
Dimensioni (MB)
Riduzione
Senza RBS
Con RBS
Dimensioni dei file di dati del database (100 GB)
106,9
3,2
97,0%
Dimensioni del backup di SQL Server (100 GB)
107,0
3,3
96,9%
Dimensioni del backup di SQL Server con
compressione (100 GB)
71,5
0,7
99,1%
Dimensioni dell’archivio BLOB (100 GB)
0
96,2
--
1120
6,5
99,4%
Dimensioni del backup di SQL Server (1 TB)
1.119,0
6,6
99,4%
Dimensioni del backup di SQL Server con
compressione (1 TB)
1.046,0
1,2
99,9%
0
1115
--
Dimensioni dei file di dati del database (1 TB)
Dimensioni dell’archivio BLOB (1 TB)
Tabella (vii) - Dimensioni del database e del backup
2
Per poter comprimere i backup dei database, è necessario utilizzare SQL Server Enterprise. Questa
caratteristica non è disponibile in SQL Server Standard o SQL Server Express.
© 2011 Microsoft Corporation. Tutti i diritti riservati.
Pagina 14
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs ([email protected]).
Microsoft SharePoint Server 2010
Aprile 2011
Figura (vi) - Dimensioni del database e del backup
Come si può notare nel grafico e nella tabella precedenti, le dimensioni del backup del database
corrispondenti al contenuto di 100 GB risultano inferiori per il 96,9% (107 GB rispetto a 3,3 GB), mentre le
dimensioni del backup del database per il contenuto di 1 TB risultano inferiori per il 99,4% (1,119 GB
rispetto a 6,6 GB) quando RBS è abilitato. Per il contenuto di 100 GB, le dimensioni degli oggetti BLOB
archiviati esternamente al database sono pari a 96,2 GB, mentre per il database di 1 TB sono pari a 1115 GB.
Quando la caratteristica di compressione dei backup di SQL Server è abilitata nel database, le dimensioni
dei backup si riducono ulteriormente, rispettivamente a 71,5 GB e 1.046 GB senza RBS e a 0,7 GB e 1,2
GB con RBS. Si noti che la compressione dei backup è efficace per la riduzione dello spazio quando non
viene utilizzato RBS, in quanto in SharePoint Server i dati BLOB vengono archiviati all’interno di righe con
gli altri dati (metadati). Se gli oggetti BLOB vengono selezionati per l’archiviazione al di fuori delle righe, la
compressione dei backup non ha alcun effetto, in quanto gli oggetti BLOB archiviati al di fuori delle righe
non vengono compressi. Benché ciò costituisca un vantaggio in questo caso, si verifica al prezzo di un
working set di dimensioni maggiori e di una minore efficienza della cache, che produce a sua volta
prestazioni inferiori.
Poiché gli oggetti BLOB di SharePoint non sono modificabili, ovvero non cambiano mai dopo che vengono
creati, è possibile eseguire il backup del contenuto BLOB in qualsiasi momento dopo il completamento del
backup del database di SQL Server. In questo modo si ottiene la flessibilità necessaria per eseguire un
rapido backup temporizzato e coerente dal punto di vista delle transazioni del database di SQL Server e
quindi un backup del volume dell’archivio BLOB in un secondo momento. Il backup di SQL Server e il
backup dell’archivio contenuto RBS costituiscono un set di backup completo del contenuto di SharePoint. Al
termine, il set di backup può essere utilizzato per ripristinare il database di SharePoint in base al momento
di inizio del backup di SQL Server. Nota: nel pianificare una strategia di backup e ripristino che comporta
l’archiviazione di dati RBS, pianificare i tempi di ripristino di RBS. Fino al ripristino di RBS, i documenti di
SharePoint non saranno disponibili.
© 2011 Microsoft Corporation. Tutti i diritti riservati.
Pagina 15
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs ([email protected]).
Microsoft SharePoint Server 2010
Aprile 2011
3. Effetti di RBS sui tempi di backup e ripristino
In questi test, i cui risultati vengono riassunti in questa sezione, sono stati misurati gli effetti di RBS sul
tempo impiegato per il backup e il ripristino di un database. Analogamente alla sezione precedente, è stato
utilizzato un database del contenuto di SharePoint di 100 GB costituito da 100.000 oggetti. È stata svolta
una serie di test per misurare il tempo necessario per il backup e il ripristino dei database con e senza RBS
abilitato. Nella tabella (viii) seguente è incluso il riepilogo dei risultati dei test per il database di 100 GB.
Operazione
Senza RBS
Con RBS
Riduzione
106,9
3,2
97,0%
Tempo necessario per il backup del database
2.490 secondi
38 secondi
98,5%
Tempo necessario per il ripristino del database
1.290 secondi
28 secondi
97,8%
Tempo necessario per il backup del database con
compressione dei backup abilitata
3.160 secondi
37 secondi
98,8%
Tempo necessario per il ripristino del database dal backup
compresso
1.330 secondi
28 secondi
97,9%
Tempo necessario per il backup dell’archivio BLOB (snapshot)
--
14 secondi
--
Tempo necessario per il ripristino dell’archivio BLOB (snapshot)
--
28 secondi
--
Tempo necessario per il backup dell’archivio BLOB
(comando di copia)
--
2.578 secondi
--
Tempo necessario per il ripristino dell’archivio BLOB
(comando di copia)
--
2.880 secondi
--
Dimensioni dei file di dati del database
Tabella (viii) - Tempi di backup e ripristino per un database di 100 GB
Figura (vii) - Tempi di backup e ripristino per un set di dati di 100 GB
© 2011 Microsoft Corporation. Tutti i diritti riservati.
Pagina 16
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs ([email protected]).
Microsoft SharePoint Server 2010
Aprile 2011
Per i backup e i ripristini del database, il tempo impiegato è direttamente proporzionale alla dimensione del
database. Poiché la dimensione del database è risultata significativamente minore con RBS abilitato, il
tempo è risultato inferiore di conseguenza, come illustrato nella figura (vii). Con RBS abilitato, la quantità
di tempo impiegata per il backup del database è risultata inferiore per il 98,5% (2.490 secondi rispetto a
38 secondi), mentre la quantità di tempo impiegata per il ripristino del database è risultata inferiore per il
97,7% (1.284 secondi rispetto a 28 secondi). Analogamente, la quantità di tempo impiegata per il backup
del database tramite la compressione dei database di SQL Server è risultata inferiore per il 98,8%, mentre
la quantità di tempo impiegata per il ripristino di un database con backup compresso è risultata inferiore
per il 97,9%. Per il backup del database con compressione dei backup è stata necessaria una quantità di
tempo maggiore del 27% e un numero significativamente maggiore di risorse del server SQL Server a
causa dell’elaborazione aggiuntiva necessaria per la compressione dei dati. I comandi utilizzati per il
backup e il ripristino dei database sono i seguenti:
BACKUP DATABASE [WSS_Content] TO DISK = N’O:\WSS_Content’ WITH NOFORMAT, INIT,
’WSS_Content-Full Database Backup’, SKIP, NOREWIND, NOUNLOAD;
NAME = N
BACKUP DATABASE [WSS_Content] TO DISK = N’O:\WSS_Content’ WITH COMPRESSION, NOFORMAT,
INIT, NAME = N’WSS_Content-Full Database Backup’, SKIP, NOREWIND, NOUNLOAD;
RESTORE DATABASE [WSS_Content] FROM DISK = N’O:\WSS_Content’ WITH FILE = 1, MOVE N’
WSS_Content’ TO N’J:\ContentDB_Data\WSS_Content.mdf’, MOVE N’WSS_Content_log’ TO N’
S:\ContentDB_Log\WSS_Content_log.LDF’, NOUNLOAD, REPLACE;
Quando si utilizza RBS, è necessario eseguire il backup dell’archivio RBS separatamente. Questo backup
può essere eseguito in modo asincrono e in parallelo con il backup del database, con l’unico requisito di
avviare il backup dell’archivio RBS dopo l’avvio del backup del database. Per eseguire il backup dell’
archivio RBS, è possibile utilizzare diversi meccanismi. Nei test trattati in questo documento è stato
misurato il tempo impiegato per il backup dell’archivio tramite un meccanismo di snapshot del disco,
nonché una semplice copia di directory sequenziale. Per i 100 GB di contenuto, il tempo impiegato per il
backup dell’archivio RBS tramite uno snapshot del disco è stato di 14 secondi, mentre quello impiegato
con il comando di copia è stato di 2.578 secondi.
Nota: quando si utilizza il provider FILESTREAM, in SharePoint 2010 vengono automaticamente eseguiti il
backup e il ripristino sia dei dati BLOB sia dei metadati.
Quando si ripristina un database con RBS abilitato, è necessario ripristinare anche l’archivio BLOB. La
farm di SharePoint viene considerata completamente ripristinata e accessibile solo al termine del ripristino
dell’archivio BLOB. Per i 100 GB di contenuto, il tempo impiegato per il ripristino dell’archivio RBS è
stato di 28 secondi utilizzando un meccanismo di snapshot del disco e di 2.880 secondi utilizzando il
comando di copia. È utile osservare che l’archivio RBS deve essere ripristinato solo nel caso in cui sia
danneggiato o sia in uno stato non coerente.
© 2011 Microsoft Corporation. Tutti i diritti riservati.
Pagina 17
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs ([email protected]).
Microsoft SharePoint Server 2010
Aprile 2011
4. Effetti di RBS sulle prestazioni di
ricostruzione degli indici
Una delle caratteristiche di SharePoint Server è la frammentazione frequente ed estesa delle tabelle del
database back-end di SQL Server in cui è archiviato il contenuto BLOB. Questa frammentazione è per molti
versi caratteristica della progettazione ed è imputabile all’architettura dell’applicazione SharePoint e al
modello di accesso del database back-end di SQL Server. Quando il database viene frammentato, le pagine
di database logicamente contigue non appaiono fisicamente contigue nel file di dati. Le pagine dati, inoltre,
vengono raramente utilizzate alla capacità completa, per cui è necessario un numero maggiore di tali
pagine a bassa densità per l’archiviazione dei dati. Entrambi questi fattori provocano dimensioni del
working set maggiori del necessario, che possono causare prestazioni inferiori.
In SharePoint 2010, tuttavia, la frammentazione viene automaticamente ridotta tramite l’esecuzione di tre
regole dell’analizzatore dell’integrità di SharePoint. Tali regole consentono di controllare regolarmente la
frammentazione degli indici e di eseguire la stored procedure proc_DefragmentIndices per deframmentare
automaticamente gli indici. È necessario tenere presente, tuttavia, che questo processo comporta un
elevato utilizzo di risorse e che l’intera farm di SharePoint diventa non disponibile durante il processo di
ricostruzione degli indici. Le tre regole sono:

I database utilizzati da SharePoint contengono indici frammentati

Uno o più database di ricerca per indicizzazione possono contenere indici frammentati

Uno o più database delle proprietà contengono indici frammentati
L’archiviazione esterna degli oggetti BLOB tramite RBS consente di ridurre significativamente questo
problema, in quanto è necessario meno tempo per ricostruire gli indici in un database di dimensioni minori.
Per misurare gli effetti della ricostruzione degli indici, è stata eseguita una serie di test in cui è stata
forzata un’operazione di ricostruzione degli indici per tutte le tabella nel database del contenuto di
SharePoint. Benché questa situazione possa non essere rappresentativa di una distribuzione reale, in cui gli
indici vengono ricostruiti in base alle esigenze, è stato scelto questo approccio per rendere il test deterministico
e ripetibile. Come parte dei test, è stato misurato il tempo impiegato per la ricostruzione di indici per database
del contenuto di 100 GB e 1 TB con e senza RBS abilitato. È stato inoltre misurato l’impatto di un’operazione di
ricostruzione degli indici sulla disponibilità e le prestazioni della farm di SharePoint.
Senza RBS
Con RBS
Riduzione
Tempi di ricostruzione degli indici per tutte le
tabelle (100 GB)
120 secondi
4 secondi
96,7%
Tempi di ricostruzione degli indici per tutte le
tabelle (1 TB)
600 secondi
146 secondi
75,7%
Tabella (x) - Frammentazione del database
Come indicato nella tabella (x) precedente, la quantità di tempo impiegata per la ricostruzione degli indici è
inferiore del 96,7% (120 secondi rispetto a 4 secondi) per il database di 100 GB e del 75,7% (600 secondi
rispetto a 146 secondi) per il database di 1 TB quando RBS è abilitato. Poiché l’applicazione Web di
SharePoint non è disponibile per la maggior parte del tempo durante la ricostruzione degli indici, la durata
© 2011 Microsoft Corporation. Tutti i diritti riservati.
Pagina 18
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs ([email protected]).
Microsoft SharePoint Server 2010
Aprile 2011
ridotta influisce direttamente sulla disponibilità dell’applicazione SharePoint e consente un’esecuzione più
frequente dell’operazione di ricostruzione degli indici, garantendo in tal modo prestazioni più coerenti.
Sono stati eseguiti più test per misurare gli effetti della ricostruzione degli indici su un database di 100 GB
senza RBS. Nella figura (viii) seguente vengono indicati i risultati per uno di tali test, in cui è stato simulato
un carico di lavoro per un caricamento di documenti e in cui è stata eseguita un’operazione di ricostruzione
degli indici durante lo stato stazionario.
Figura (viii) - Effetti dell’operazione di ricostruzione degli indici sulle prestazioni
Come è possibile osservare durante il normale funzionamento (dalle 6.28 alle 6.56), la velocità di
caricamento dei file prevista è in media di 85 file al secondo. Alle 6.56 è stata eseguita un’operazione di
ricostruzione degli indici, durata 120 secondi. Durante questo periodo di tempo la velocità di caricamento
dei file è calata fino quasi a zero, come indicato nel grafico. Questo dato suggerisce che l’insieme di
operazioni utente eseguite durante questo periodo di tempo viene bloccato per un timeout di almeno 120
secondi e produce la visualizzazione di un messaggio di errore all’utente finale.
Considerando che l’operazione di ricostruzione degli indici quando RBS è abilitato nel database dura solo 4
secondi, l’intervallo è talmente minimo che l’impatto non è visibile. La flessione nelle prestazioni è talmente
irrilevante da essere di difficile rappresentazione nel grafico ed è stata pertanto intenzionalmente omessa
dal grafico. Benché il test sia stato eseguito utilizzando un caricamento di file come carico di lavoro,
l’effetto sulla disponibilità della farm di SharePoint è identico su tutti i tipi di transazioni.
© 2011 Microsoft Corporation. Tutti i diritti riservati.
Pagina 19
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs ([email protected]).
Microsoft SharePoint Server 2010
Aprile 2011
5. Effetti di RBS sui tempi di risposta delle
transazioni di SharePoint
Come descritto nella sezione precedente, l’abilitazione della caratteristica RBS produce database del
contenuto di SharePoint di dimensioni minori, che a loro volta richiedono un numero inferiore di risorse nel
server di database SQL Server per l’esecuzione di query. Le risorse risparmiate vengono liberate per
elaborare più rapidamente le query esistenti e per gestire più query.
In questi test, i cui risultati vengono riassunti in questa sezione, sono stati misurati gli effetti
dell’abilitazione di RBS sui tempi di risposta delle transazioni. Per i test è stato utilizzato come carico di
lavoro la combinazione completa di transazioni di SharePoint, illustrata nella sezione Metodologia dei test.
Questo carico di lavoro è stato eseguito in 6 driver di carico che hanno simulato un carico utente di 100
utenti che eseguono la transazione di SharePoint in media ogni 15 secondi. Ogni test è stato intensificato
per 5 minuti e quindi eseguito continuamente per una durata di 2 ore. I tempi medi di risposta sono stati
misurati complessivamente per le due ore di prestazioni in stato stazionario del test. Nella tabella (xi)
seguente vengono indicati questi risultati di alto livello.
Criterio di valutazione
Senza RBS
Con RBS
Riduzione
Carico utente massimo
100
100
0,0%
Richieste al secondo
84
84,3
-0,4%
Richieste non riuscite
0
0
Tempo medio di risposta
28 millisecondi
21
millisecondi
25,0%
Test al secondo
6,4
6,42
-0,3%
Tempo medio pagina
210 millisecondi
160
millisecondi
23,8%
0,0%
Tabella (xi) - Criteri di valutazione per i test sui tempi di risposta delle transazioni
Il tempo medio di risposta in tutte le transazioni è risultato minore del 25% (28 millisecondi rispetto a 21
millisecondi) quando RBS è abilitato nel database del contenuto. Questo dato suggerisce che quando RBS è
abilitato, in media i tempi di risposta delle transazioni di SharePoint per gli utenti finali sono più rapidi del
25% in un’ampia gamma di transazioni. Considerando che la produttività e la soddisfazione degli utenti di
SharePoint dipendono spesso dai tempi di risposta delle transazioni di SharePoint, una riduzione del 25%
produce livelli superiori di produttività e soddisfazione.
Nella tabella (xii) seguente vengono suddivisi ulteriormente i tempi di risposta per ciascuna delle
quattordici transazioni degli utenti finali.
Transazione
Percentua
le
transazio
ne
Durata media della
transazione (s)
Senza
RBS
Riduzione
Con RBS
Pagina pubblica Sito personale
16,0%
0,14
0,08
42,9%
Home page
25,0%
0,43
0,22
48,8%
Flusso di lavoro pagine
1,1%
109,00
109,00
0,0%
Creazione di una pagina
6,0%
15,72
15.67
0,3%
© 2011 Microsoft Corporation. Tutti i diritti riservati.
Pagina 20
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs ([email protected]).
Microsoft SharePoint Server 2010
Aprile 2011
Creazione di un sito di
pubblicazione
1,0%
13,00
12,70
2,3%
Creazione di un sito del team
1,0%
17,90
18,30
-2,2%
12,2%
4,03
4,03
0,0%
6,9%
29,84
29,90
-0,2%
Pagina grande
10,1%
0,12
0,09
25,0%
Query di ricerca
14,8%
60,00
60,10
-0,2%
Strumento di gestione del sito
1,0%
0,45
0,31
31,1%
Caricamento di documenti
4,9%
30,20
30,50
-1,0%
Download di un documento
Pagina Modifica profilo per Sito
personale
Tabella (xii) - Tempi di risposta delle transazioni
Figura (ix) - Tempi di risposta delle transazioni
Come illustrato in precedenza, i tempi medi di risposta per 10 delle 14 transazioni sono uguali o migliori quando
RBS è abilitato, mentre quattro delle transazioni mostrano un miglioramento prossimo al 50%. Per le quattro
transazioni con un rallentamento delle prestazioni, il rallentamento è inferiore al 2,2% e nella maggior parte dei
casi non risulta osservabile da un utente reale. In generale, quando RBS è abilitato, è probabile che si osservi un
miglioramento delle prestazioni per file di grandi dimensioni, in particolare per i sistemi di I/O associati, in quanto
l’I/O viene reindirizzato all’esterno del database di SQL Server. Per file di dimensioni minori può verificarsi un
relativo peggioramento delle prestazioni, in quanto il front-end Web deve emettere due richieste via cavo anziché
una. È tuttavia probabile che l’aumento relativo non sia osservabile anche nel caso di una differenza in percentuale
elevata, perché i tempi di accesso ai file sono trascurabili.
© 2011 Microsoft Corporation. Tutti i diritti riservati.
Pagina 21
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs ([email protected]).
Microsoft SharePoint Server 2010
Aprile 2011
6. Effetti di RBS sulle prestazioni della ricerca
per indicizzazione
La ricerca è una componente integrante della maggior parte delle distribuzioni di SharePoint e uno dei
servizi di SharePoint che comporta l’utilizzo più elevato di risorse. Molte distribuzioni aziendali prevedono
una percentuale elevata di utenti che accedono ai dati dal portale di ricerca, anziché accedere direttamente
al sito o al documento. Poiché questo comportamento provoca un ingente utilizzo della ricerca, non
sorprende come per molti clienti la ricerca sia diventata la principale causa di utilizzo delle risorse o
costituisca spesso un collo di bottiglia.
La ricerca di SharePoint è costituita da due componenti, ovvero la ricerca per indicizzazione e la query di
ricerca. Tramite il processo di ricerca per indicizzazione i crawler eseguono la ricerca nel corpo di ricerca e
costruiscono, o aggiornano, l’indice di ricerca. L’indice di ricerca di SharePoint è costituito da due parti,
ovvero un database di ricerca e un file flat dell’indice di ricerca. Le query di ricerca a loro volta utilizzano il
database e l’indice di ricerca per restituire risultati per query di ricerca degli utenti.
In questi test, i cui risultati vengono riassunti in questa sezione, è stato misurato il tempo impiegato per la
ricerca per indicizzazione nel corpo di ricerca tramite un singolo server applicazioni con impostazioni di
ricerca predefinite. Nella tabella (xiii) seguente viene presentato il riepilogo dei risultati per il tempo
impiegato con e senza RBS. I risultati della query di ricerca sono già stati riassunti nella sezione precedente
e pertanto non verranno ripetuti in questa sezione.
Operazione
N. di oggetti
Senza RBS
Con RBS
Riduzione
Ricerca per
indicizzazione
completa
503.206
150 minuti
146 minuti
2,7%
Tabella (xiii) - Tempi necessari per la ricerca per indicizzazione
Figura (x) - Riepilogo della ricerca per indicizzazione completa
Come indicato nei risultati precedenti, l’abilitazione di RBS nei database del corpo di ricerca ha un effetto
molto trascurabile sulle prestazioni, migliorandole solo del 2,7%. Questo dato è in linea con le previsioni, in
quanto l’elaborazione eseguita in entrambi i casi è all’incirca identica.
© 2011 Microsoft Corporation. Tutti i diritti riservati.
Pagina 22
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs ([email protected]).
Microsoft SharePoint Server 2010
Aprile 2011
7. Effetti di RBS sulle prestazioni di caricamento
dei file
La quantità di tempo impiegata per caricare file di grandi dimensioni in SharePoint Server è spesso un
fattore limitante per gli utenti che caricano quantità elevate di contenuto. La critica più comune è che la
copia di un file in una condivisione di file di Windows è in genere estremamente più rapida del caricamento
dello stesso file in SharePoint Server. Uno dei motivi è che, per impostazione predefinita, tutto il contenuto
del file viene archiviato nel database di SQL Server e comporta un overhead associato. Considerando,
inoltre, che il database di SQL Server opera in un modello coerente dal punto di vista delle transazioni,
deve registrare l’intero oggetto BLOB nel registro delle transazioni di SQL Server, oltre ad archiviarne la
copia effettiva nel database, producendo di conseguenza un carico di I/O doppio sul sistema. RBS migliora
notevolmente le prestazioni dei caricamenti di file di grandi dimensioni, in quanto archivia l’oggetto BLOB
direttamente all’esterno del front-end Web, riducendo al minimo il carico di I/O sul sistema SQL Server.
In questi test, i cui risultati vengono riassunti in questa sezione, è stata definita una distribuzione per la
gestione delle risorse digitali di SharePoint e sono state misurate le prestazioni del caricamento di file di
grandi dimensioni, comprese tra 1 MB e 1,99 GB, con e senza RBS abilitato. Nella tabella (xiv) seguente
vengono illustrati i risultati per il tempo impiegato per il caricamento di file con e senza RBS.
Dimensioni dei file
Tempo impiegato per il caricamento
di un file (secondi)
Riduzione
Senza RBS
Con RBS
1 MB
1,2
1,0
16,7%
100 MB
12,2
9,7
20,5%
500 MB
55
28,8
47,6%
1 GB
69,4
48
30,8%
1,5 GB
138
71
48,6%
1,99 GB
178
87
51,1%
Tabella (xiv) - Tempi di caricamento dei file
© 2011 Microsoft Corporation. Tutti i diritti riservati.
Pagina 23
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs ([email protected]).
Microsoft SharePoint Server 2010
Aprile 2011
Figura (xi) - Tempi di caricamento dei file
Come illustrato nella tabella e nel grafico, il tempo impiegato per il caricamento di un file con RBS è più
veloce del 15%-50% rispetto ai casi in cui RBS non è abilitato. In termini assoluti, questo dato si traduce
nel caricamento di un file di 1,99 GB in 87 secondi anziché in 178 secondi, che costituisce una riduzione
significativa per gli utenti di centri record che caricano file, se si considera che tali utenti sono spesso
costretti ad attendere il completamento dell’operazione nel Web browser prima di proseguire l’attività. In
organizzazioni con centinaia di utenti che eseguono ciascuno dieci o più di tali operazioni, il risparmio di
tempo e i vantaggi aumentano notevolmente e sono particolarmente evidenti nel caso di un collo di
bottiglia relativo alle risorse nel server.
Vantaggi simili si verificano anche per le operazioni di download di file, anche se in questi casi il sistema
SQL Server e il front-end Web SharePoint memorizzano i dati dei file nel buffer, producendo un minor
consumo di risorse nell’archiviazione back-end.
© 2011 Microsoft Corporation. Tutti i diritti riservati.
Pagina 24
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs ([email protected]).
Microsoft SharePoint Server 2010
Aprile 2011
8. Tempo necessario per la migrazione dei dati
Dopo aver abilitato RBS in un database, tutti i file caricati o modificati vengono automaticamente archiviati
esternamente nell’archivio BLOB di RBS associato al provider attivo. Gli oggetti precedentemente archiviati
nel database restano nel database ed è possibile accedervi sempre dal database. Tali oggetti non vengono
automaticamente migrati esternamente nell’archivio RBS. In questa configurazione SharePoint semplifica
l’accesso sia ai file archiviati esternamente tramite RBS, sia a quelli ancora archiviati nel database.
Benché questo meccanismo funzioni in modo adeguato, nel tempo gli utenti potrebbero voler eseguire la
migrazione di tutto il contenuto esistente archiviato nel database all’archivio RBS esterno oppure eseguire
la migrazione di tutto il contenuto archiviato esternamente in RBS di nuovo al database. Entrambe le
operazioni possono essere eseguite tramite il cmdlet Windows PowerShell™ 2.0 Migrate() , disponibile in
SharePoint Server 2010. L’esatta sequenza dei comandi Windows PowerShell da eseguire viene indicata
nello script seguente.
$cdb=Get-SPContentDatabase <NomeDatabaseContenuto>
$rbss=$cdb.RemoteBlobStorageSettings
$rbss.GetProviderNames()
$rbss.SetActiveProviderName($rbss.GetProviderNames()[0])3
$rbss.Migrate()
È necessario eseguire questi passaggi per ogni database in cui si desidera eseguire la migrazione degli
oggetti BLOB. L’esecuzione dello script di Windows PowerShell quando il provider RBS è abilitato produce la
migrazione degli oggetti BLOB esternamente al database e nell’archivio RBS, mentre l’esecuzione dello
script di Windows PowerShell quando il provider è disabilitato produce una nuova migrazione degli oggetti
BLOB nel database.
Considerando che un database del contenuto può contenere migliaia o persino milioni di oggetti archiviati, è
necessario valutare con attenzione la situazione prima di eseguire la migrazione, in quanto il completamento delle
operazioni può richiedere molto tempo. È consigliabile eseguire il cmdlet Migrate() in fasce orarie non di punta e da
un server applicazioni o front-end Web SharePoint non utilizzato in modo troppo gravoso.
In questi test è stato eseguito lo script precedente dal server applicazioni per effettuare la migrazione di
500.000 oggetti di SharePoint, ciascuno dei quali con una dimensione media di 100 KB, da e verso il
database. Nella tabella (xv) seguente viene presentato un riepilogo dei risultati dei test.
Operazione
Tempo
impiegato
(minuti)
Oggetti BLOB
migrati al secondo
Migrazione di dati dal database del contenuto all’archivio
BLOB (archiviazione esterna di dati)
243
34,3
Migrazione di dati dall’archivio BLOB al database del
contenuto (archiviazione interna di dati)
504
16,5
Tabella (xv) - Tempi di migrazione di oggetti BLOB di RBS
3
Nota: $rbss.GetProviderNames()[0] corrisponde al provider RBS di StorSimple.
© 2011 Microsoft Corporation. Tutti i diritti riservati.
Pagina 25
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs ([email protected]).
Microsoft SharePoint Server 2010
Aprile 2011
Il tempo aggiuntivo impiegato per la migrazione di dati nel database del contenuto è imputabile all’ulteriore
elaborazione di SharePoint Server e SQL Server necessaria nel back-end. Per garantire la confrontabilità
dei risultati e la loro conformità con i requisiti di supporto Microsoft, non è stata eseguita altra ottimizzazione nel
database di SQL Server a parte quella indicata nella sezione relativa alla configurazione software.
È possibile riavviare il metodo RBS Migrate per avviare la migrazione di oggetti BLOB da e verso il database
dalla posizione in cui si trovano dalla chiamata precedente.
Conclusioni
In questo documento è stato descritto come l’utilizzo di RBS possa contribuire alla riduzione dell’effettiva
dimensione del database del contenuto di SharePoint e delle dimensioni dei backup per oltre il 95%,
riducendo di conseguenza i tempi di backup e offrendo la possibilità di utilizzare archiviazione meno
costosa per archiviare dati BLOB. È stato quindi illustrato come la caratteristica RBS aiuti gli utenti ad
archiviare in SharePoint Server file multimediali di grandi dimensioni e a ottenere tutti i vantaggi di
SharePoint Server senza produrre colli di bottiglia nel database di SQL Server o rendere la soluzione
eccessivamente cara. Sono stati inoltre analizzati gli effetti di RBS sui tempi di ricerca per indicizzazione,
sulle prestazioni dell’attività di manutenzione della ricostruzione degli indici (con una riduzione del 96%) e
sui tempi di risposta delle transazioni degli utenti finali (con una riduzione del 30% o ancora maggiore per
alcune transazioni). Sono stati infine misurati le prestazioni del caricamento di singoli file multimediali di
grandi dimensioni e il tempo impiegato per la migrazione di dati BLOB da e verso il database tramite RBS.
Nel complesso, è stato rilevato che l’utilizzo di RBS semplifica la gestibilità di una farm di SharePoint,
migliorando la scalabilità della soluzione. Questi vantaggi si traducono a loro volta in un risparmio dei costi
e in un’esperienza utente migliore. Quando RBS viene utilizzato per operazioni di manutenzione come il
backup dell’archivio BLOB, tuttavia, deve essere attentamente pianificato e inserito nell’elenco delle attività
di manutenzione.
© 2011 Microsoft Corporation. Tutti i diritti riservati.
Pagina 26
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs ([email protected]).
Microsoft SharePoint Server 2010
Aprile 2011
Risorse aggiuntive
Panoramica di Archiviazione BLOB remoti: http://technet.microsoft.com/it-it/library/ee748649.aspx (le
informazioni potrebbero essere in lingua inglese)
Eseguire la migrazione di contenuto in e da RBS: http://technet.microsoft.com/it-it/library/ff628254.aspx
(le informazioni potrebbero essere in lingua inglese)
Utilità StorSimple di ottimizzazione del database di SharePoint: http://www.storsimple.com/ (le
informazioni potrebbero essere in lingua inglese)
Test di carico sulle prestazioni di Microsoft Office SharePoint Server 2007:
http://sptdatapop.codeplex.com/releases/view/1214#DownloadId=6918 (le informazioni potrebbero
essere in lingua inglese)
Microsoft® SQL Server® 2008 R2 Feature Pack:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=ceb4346f-657f-4d28-83f5aae0c5c83d52
Informazioni su StorSimple
La soluzione di StorSimple consente di risolvere importanti problemi di archiviazione relativi a prestazioni,
scalabilità, gestibilità, protezione dei dati e costi per Microsoft SharePoint Server 2010. StorSimple
consente di distribuire archiviazione locale di prossima generazione per affrontare le attuali sfide correlate
alle applicazioni, utilizzando archiviazione in cloud pubblica e privata in base alle proprie tempistiche.
Ulteriori informazioni su StorSimple sono disponibili all’indirizzo www.storsimple.com (le informazioni
potrebbero essere in lingua inglese).
Informazioni su Microsoft
Microsoft Corporation è una multinazionale pubblica con sede a Redmond (Washington, Stati Uniti) che
sviluppa, produce, concede in licenza e supporta un’ampia gamma di prodotti e servizi prevalentemente
informatici attraverso diverse divisioni di prodotto.
© 2011 Microsoft Corporation. Tutti i diritti riservati.
Pagina 27
Per commenti su questo documento o per richiedere altra documentazione su queste caratteristiche, contattare
SharePoint IT Docs ([email protected]).