Performances du stockage BLOB distant SQL Server avec …download.microsoft.com/download/7/8/5/785A7616-BE9C-4978... · 2018. 10. 15. · Performances du stockage BLOB distant SQL

Performances du stockage BLOB distant SQL Server avec SharePoint Server 2010 et la solution de stockage StorSimple

Ce document est fourni en l’état. Les informations et les vues contenues dans ce document, y compris les

URL et autres références de site Web Internet, sont susceptibles d’être modifiées sans préavis. Vous les

utilisez à vos risques.

Ce document ne vous confère aucun droit sur la propriété intellectuelle contenue dans quelque produit

Microsoft que ce soit. Vous pouvez copier ou utiliser ce document pour vos propres besoins de référence

internes. Vous ne pouvez pas modifier ce document pour vos propres besoins internes ou de référence.

© 2011 Microsoft Corporation. Tous droits réservés.

Microsoft SharePoint Server 2010 Avril 2011

© 2011 Microsoft Corporation. Tous droits réservés. Page 2

Pour commenter ce document ou demander de la documentation supplémentaire sur ces fonctionnalités,

contactez le service de documentation informatique SharePoint

Performances du stockage BLOB distant SQL Server avec SharePoint Server 2010 et la solution de stockage StorSimple

Burzin Patel

StorSimple, Inc.

Peter Scharlock

Microsoft Corporation

Réviseurs techniques : John Flores (StorSimple, Inc.), Srini Acharya, Steve Howard, Shaun Tinline-Jones,

Mike Weiner, Kun Cheng, Prem Mehra, Jimmy May, David Koronthaly, Bill Baer

Décembre 2010 ; révision en avril 2011

S’applique à : SharePoint Server 2010 et SQL Server 2008 R2

Résumé : la technologie Microsoft ® SharePoint® a vu son utilisation augmenter de manière significative

au cours des dernières années. Cette augmentation est due au fait que les utilisateurs stockent un nombre

élevé de documents dans les bibliothèques SharePoint, ainsi que des documents multimédias plus

volumineux, avec à la clé un accroissement des coûts de stockage, ainsi que certains défis posés aux

administrateurs SharePoint en termes de performances et de facilité de gestion. Microsoft a résolu ces

problèmes en introduisant la prise en charge native de la fonctionnalité RBS (Remote BLOB Storage,

stockage BLOB distant) dans SharePoint Server 2010. Ce document explique la fonctionnalité RBS telle

qu’elle s’applique à SharePoint Server 2010 et analyse l’incidence de ses performances sur une série

d’attributs clés d’une batterie de serveurs SharePoint, tels que la taille de la base de données, la taille de la

sauvegarde de la base de données, les temps de réponse des transactions et la durée de la

sauvegarde/restauration.





Sommaire

Introduction ...................................................................................................................................................... 4 Stockage BLOB distant ........................................................................................................................................ 4

Pourquoi utiliser RBS .................................................................................................................................... 5 Objectifs des tests .............................................................................................................................................. 6 Méthodologie des tests ....................................................................................................................................... 7

Charge de travail ......................................................................................................................................... 7

Configuration du serveur............................................................................................................................... 9

Configuration matérielle ....................................................................................................................... 10

Configuration du stockage .................................................................................................................... 10

Configuration logicielle ......................................................................................................................... 11 Résultats des tests et observations ..................................................................................................................... 11

1. Impact du stockage BLOB distant sur la taille de la base de données SQL Server ........................................... 12

2. Impact du stockage BLOB distant sur la taille de la sauvegarde des bases de données .................................... 14

3. Impact du stockage BLOB distant sur les durées de la sauvegarde et de la restauration .................................. 17

4. Impact du stockage BLOB distant sur les performances de la reconstruction des index.................................... 19

5. Impact du stockage BLOB distant sur les temps de réponse des transactions SharePoint ................................. 21

6. Impact du stockage BLOB distant sur les performances d’analyse................................................................. 23

7. Impact du stockage BLOB distant sur les performances de transfert ............................................................. 24

8. Durée requise pour la migration des données ............................................................................................ 26 Conclusion....................................................................................................................................................... 28 Ressources supplémentaires .............................................................................................................................. 28 À propos de StorSimple .................................................................................................................................... 29 À propos de Microsoft ....................................................................................................................................... 29





Introduction Au cours des dernières années, Microsoft SharePoint Server a gagné en popularité de façon pratiquement

exponentielle. Ce gain s’explique par l’adoption croissante de SharePoint Server, ainsi que par le stockage

de documents et de jeux de données plus volumineux sur les batteries de serveurs SharePoint. Avec le

lancement récent de SharePoint Server 2010, cette augmentation de l’utilisation devrait s’amplifier.

SharePoint Server 2010 offre une interface utilisateur plus rationalisée qui procure une expérience

utilisateur plus riche, faisant de SharePoint Server le référentiel de choix pour tous les types de données.

Cela, ainsi que la croissance du contenu multimédia enrichi, entraîne une augmentation considérable de la

taille du contenu des batteries de serveurs SharePoint, ce qui se traduit par un accroissement significatif du

stockage physique requis. Cette augmentation de la taille pose souvent un défi aux administrateurs

SharePoint qui doivent désormais gérer davantage de contenu, ainsi que des bases de données et des

sauvegardes plus volumineuses. Pour résoudre tous ces problèmes, SharePoint Server 2010 introduit une

nouvelle fonctionnalité, le stockage BLOB distant (RBS), qui permet de gérer l’accroissement du contenu

SharePoint.

Ce document présente les avantages et les caractéristiques opérationnelles de la fonctionnalité RBS dans le

cadre d’une utilisation avec Microsoft SharePoint Server 2010. Il présente également les caractéristiques

des performances d’une batterie de serveurs SharePoint configurée de manière à fonctionner avec la

solution de stockage StorSimple, comme expliqué dans la section suivante. Les avantages, tels que la

réduction de la taille de la base de données, l’accélération des sauvegardes de base de données,

l’accélération des restaurations de base de données, la réduction des temps de réponse pour les

documents plus volumineux, une sollicitation moindre du stockage principal, ainsi que les avantages en

termes de maintenance de base de données, seront abordés avec les points de données de performances

correspondants. Tous les points de données présentés dans le document ont été générés dans le cadre des

tests de performance effectués dans les laboratoires de performance de StorSimple, Inc. à Santa Clara

(États-Unis) conjointement avec les équipes de produit Microsoft SQL Server et SharePoint.

Remarque : les résultats des tests indiqués dans ce livre blanc sont spécifiques aux

environnements décrits. Vos résultats peuvent varier.

Stockage BLOB distant BLOB est l’acronyme de Binary Large Object et, dans le cadre d’une application SharePoint, fait référence à

l’objet fichier stocké dans la base de données. Le stockage BLOB distant (RBS) est un ensemble d’API de

bibliothèque Microsoft® SQL Server® incorporé en tant que Feature Pack complémentaire pour Microsoft

SQL Server 2008 R2. La fonctionnalité RBS permet aux applications d’externaliser le stockage des objets

BLOB en dehors de la base de données, par exemple, dans un partage de fichiers, ce qui permet de réduire

la quantité de stockage de base de données SQL Server requise. Un magasin RBS est généralement un

volume distinct sur le même réseau que SQL Server. SharePoint Server 2010 s’appuie sur la fonctionnalité

RBS pour externaliser les objets BLOB stockés dans la base de données de contenu. SQL Server et

SharePoint Server gèrent conjointement l’intégrité des données entre les enregistrements des bases de

données et le magasin externe RBS au niveau de chaque base de données.

La fonctionnalité RBS SQL Server requiert l’installation d’un fournisseur sur chaque serveur Web frontal

SharePoint sur lequel l’application SharePoint est configurée. Le fournisseur se compose d’un ensemble de

DLL qui implémentent des méthodes pour les API RBS et qui se chargent de l’externalisation des objets

BLOB.





Pour tous les tests mentionnés dans ce document, l’optimiseur de base de données SharePoint StorSimple,

qui comprend un fournisseur de stockage BLOB distant, a été configuré sur la batterie de serveurs

SharePoint Server 2010. La configuration a été réalisée à l’aide du gestionnaire de configuration du

stockage BLOB distant de l’optimiseur de base de données SharePoint StorSimple, qui est une extension du

site Web Administration centrale, comme le montre la figure (i) ci-après.

Figure (i) – Optimiseur de base de données SharePoint StorSimple - Configuration du stockage BLOB distant

Pourquoi utiliser RBS SharePoint Server stocke toutes ses données dans la base de données. À mesure que le contenu stocké

s’accroît, la taille de la base de données peut augmenter très rapidement. Cette augmentation est liée au

nouveau contenu téléchargé vers SharePoint Server, ainsi qu’aux révisions du contenu existant lorsque le

contrôle de version SharePoint est activé ; la modification du moindre octet d’un document SharePoint

entraîne le stockage d’une nouvelle copie de l’objet BLOB entier dans la base de données et le marquage

de la copie précédente en tant qu’ancienne version. Comme l’ont déjà constaté de nombreux

administrateurs SharePoint, cela aboutit à une croissance exponentielle de la taille du contenu.

À mesure que la taille de la base de données augmente, il devient de plus en plus difficile de gérer le

système et de garantir des performances optimales. L’exécution de tâches fondamentales telles que la

sauvegarde et la restauration, ainsi que la défragmentation des bases de données, s’avère de plus en plus

délicate. C’est l’une des raisons pour lesquelles Microsoft recommande aux clients de limiter la taille de

leurs bases de données à une taille gérable, comme expliqué dans l’article : « Gestion de la capacité

SharePoint Server 2010 : limitations et frontières logicielles » (http://technet.microsoft.com/fr-

fr/library/cc262787.aspx#ContentDB). L’adhésion à cette recommandation de meilleure pratique peut

http://technet.microsoft.com/fr-fr/library/cc262787.aspx#ContentDB

http://technet.microsoft.com/fr-fr/library/cc262787.aspx#ContentDB





amener l’administrateur SharePoint à créer plusieurs bases de données, ce qui peut s’avérer coûteux en

termes de gestion et de maintenabilité. Un accroissement du nombre de bases de données entraîne une

augmentation du nombre de sauvegardes à gérer et à surveiller, ce qui nécessite un nombre accru

d’administrateurs SharePoint.

Grâce au stockage BLOB distant, votre application peut stocker de grandes quantités de données non

structurées telles que des vidéos multimédias enrichies ou des fichiers audio, tirant au maximum parti des

fonctionnalités relationnelles de SQL Server et de l’évolutivité d’un magasin BLOB du système de fichiers

Windows®. Outre cet avantage principal, la fonctionnalité RBS présente de nombreux avantages en

termes de coûts de stockage, de maintenabilité, de performance et de souplesse :

réduction de la taille des bases de données, ce qui permet une utilisation optimale des ressources

coûteuses des serveurs de bases de données telles que les processeurs, la mémoire et les disques ;

réduction des fichiers de sauvegarde des bases de données ;

réduction de la durée des sauvegardes et des restaurations ;

réduction de la durée des opérations de maintenance de base de données telles que la défragmentation

et la reconstruction des index ;

amélioration des performances globales, notamment pour le stockage des objets volumineux et l’accès

à ceux-ci.

Lorsque SharePoint Server est configuré pour utiliser RBS, la sémantique transactionnelle des opérations

utilisateur est entièrement conservée et rien n’est modifié du point de vue de l’utilisateur. La tâche

d’externalisation des objets BLOB à partir de la base de données est réalisée automatiquement sur le

serveur principal par SharePoint Server conjointement avec le fournisseur de stockage BLOB distant. Le

stockage BLOB distant s’exécute de façon transparente lorsqu’il est utilisé avec le clustering de

basculement SQL Server , toutefois, il ne fonctionne pas avec la mise en miroir SQL Server lorsque la base

de données de contenu SharePoint est mise en miroir sur un serveur de bases de données dans une autre

batterie de serveurs.

Objectifs des tests L’objectif des tests consistait à évaluer les performances d’une batterie de serveurs SharePoint configurée avec la fonctionnalité RBS en utilisant le fournisseur de stockage BLOB distant StorSimple, qui fait partie de l’optimiseur de base de données SharePoint StorSimple, puis à comparer ces performances à celles d’une batterie de serveurs SharePoint sur laquelle la fonctionnalité RBS n’est pas activée. Nous souhaitions également mesurer l’impact du stockage BLOB distant sur les éléments suivants :

données des bases de données SQL Server et taille des fichiers journaux de transactions ;

taille des fichiers de sauvegarde ;

durée de la sauvegarde et de la restauration de la base de données de contenu ;

durée de la reconstruction des index de la base de données de contenu ;

impact de la reconstruction des index sur les performances des transactions utilisateur final ;

temps de réponse des transactions SharePoint ;

opération d’analyse de recherche SharePoint Server ;

performances du transfert de fichiers ;

cohérence des performances à mesure que l’échelle du contenu augmente ;

durée de la migration des données vers et depuis le magasin RBS.

Le comportement de SharePoint Server 2010 suivant différentes configurations de charge de travail d’application ou différents seuils pour la taille des objets BLOB externalisés n’entre pas dans le cadre de ce

document.





Méthodologie des tests Notre objectif consistait à effectuer les tests décrits dans la section précédente par rapport à une charge de

travail représentant aussi étroitement que possible des scénarios réalistes. Un autre objectif consistait à

garder une configuration de test (configuration du serveur, paramètres de base de données, schéma de

tables, etc.) relativement constante d’un test à l’autre afin de pouvoir comparer les performances des

différentes opérations.

Les tests ont été généralement divisés en 3 catégories : (1) tests de transfert, (2) tests de combinaison de

transactions complètes et (3) tests divers.

Tests de transfert de documents : cet ensemble de tests a mesuré les performances du stockage BLOB

distant et son impact sur le transfert de documents utilisateur suivant différentes tailles de fichier

moyennes.

Tests de combinaison de transactions SharePoint complètes : cet ensemble de tests a mesuré

l’impact du stockage BLOB distant sur les performances de la batterie de serveurs SharePoint. Les tests

comprenaient toutes les transactions utilisateur SharePoint couramment exécutéestelles quel’exploration,

la recherche, le transfert de document et la création de site. La mesure de performance principalement

utilisée était le temps de réponse moyen des pages Web.

Tests divers : ces tests comprenaient des opérations telles que la sauvegarde et la restauration de base

de données, la migration d’objets depuis et vers la base de données et vers le magasin RBS, ainsi que

l’analyse de recherche SharePoint Server.

Charge de travail La diversité des questions auxquelles les tests devaient répondre nous a amenés à utiliser différents jeux

de données de charge de travail. Deux charges de travail ont été utilisées pour les tests : (1) la charge de

travail de transfert de fichiers et (2) la combinaison de transactions SharePoint complètes.

La charge de travail de transfert de fichiers comprenait deux ensembles de fichiers d’une taille pondérée

moyenne d’environ 100 Ko, pour la génération de la base de données de 100 Go, et 500 Ko, pour la

génération de la base de données de contenu d’un To. La figure (ii) indique la répartition des tailles de

fichier pour le jeu de données de 100 Ko.





Figure (ii) – Répartition des tailles de fichier de la charge de travail

La charge de travail de transfert de fichiers a essentiellement servi à évaluer les performances de transfert

de document avec et sans le stockage BLOB distant.

La combinaison de transactions SharePoint complètes a servi à représenter une combinaison de

transactions SharePoint susceptibles d’être exécutées quotidiennement par un utilisateur final. Microsoft

Visual Studio® Team System 2008 Team Suite a été utilisé pour générer la charge de travail à l’aide d’une

version modifiée de la boîte à outils des performances Microsoft Office SharePoint Server 2007 d’origine

partagée sur Codeplex. Les transactions suivantes ont été utilisées pour chaque test.

Nom du test Description Pourcentage

Flux de travail de page

Parcourir un flux de travail de page : extraire, approuver et archiver.

1%

Créer une page Créer une page. 6%

Gestionnaire de site Ouvrir la vue du gestionnaire de site. 1%

Créer un site de publication

Créer un site avec le modèle de publication. 1%

Créer un site

d’équipe

Créer une collection de sites à l’aide du modèle de site

d’équipe sous le répertoire sites. 1%

Page d’accueil Accéder à la page d’accueil du portail. 25%





Grande page Accéder à de nombreuses pages sur le portail. 10%

Page Site Mon site publique

Accéder à la page publique Site Mon site. 16%

Modifier le profil du

site Mon site Modifier le profil personnel. 7%

Requête de recherche

Effectuer une requête de recherche et afficher les résultats dans la page Centre de recherche.

15%

Transférer un document

Transférer un document (taille moyenne de 90 Ko). 5%

Télécharger un document

Téléchargerun document (taille moyenne de 90 Ko). 12%

Total : 100%

Tableau (i) – Combinaison de transactions SharePoint complètes.

Configuration du serveur La batterie de serveurs SharePoint a été configurée avec six serveurs Web frontaux, un serveur d’applications configuré pour exécuter le robot de recherche et un serveur de bases de données, comme l’illustre la figure (iii).

Les serveurs Web frontaux et le serveur d’applications ont été configurés de manière à s’exécuter sur un

ordinateur virtuel, tandis que le serveur de bases de données était exécuté sur un serveur physique dédié

(non virtualisé). En outre, six serveurs de pilotage de charge basés sur un ordinateur virtuel (non illustrés ci-dessus) ont été utilisés pour générer la

charge de travail de la combinaison de transactions de transfert de fichiers et la combinaison de

transactions SharePoint complètes.

Figure (iii) - Topologie de la batterie de serveurs SharePoint





Configuration matérielle Rôle d’ordinateur Matériel

Serveurs Web frontaux

2 processeurs Intel Xeon E5504 2 GHz (virtualisés)

8 Go de RAM

Serveur d’applications

2 processeurs Intel Xeon 2 GHz (virtualisés)

8 Go de RAM

Serveur de bases de données

2 processeurs Intel Xeon 2 GHz quadruple cœur (non virtualisés)

16 Go de RAM (12 Go affectés à SQL Server)

Tableau (ii) – Configuration matérielle

Configuration du stockage La totalité du stockage utilisé dans les tests d’évaluation a été configurée sur le dispositif de stockage

StorSimple 10101. Les bases de données système SQL Server, les bases de données SharePoint et le

magasin BLOB se trouvaient sur des volumes distincts, comme l’indique le tableau (iii) ci-après.

Tableau (iii) – Configuration du stockage

1StorSimple 1010 est un dispositif de stockage optimisé destiné aux applications, telles que Microsoft SharePoint et

Microsoft Exchange. Pour plus d’informations, consultez la page http://www.storsimple.com.

Volume Lecteur

Bases de données système SQL C:\

Fichiers journaux et données tempdb

H:\

Fichier de données de la base de données de contenu

P:\

Fichier journal de la base de

données de contenu

Q:\

Fichier de données de la base de données de recherche

S:\

Fichier journal de la base de données de recherche

Q:\

Magasin BLOB X:\

Sauvegardes O:\

http://www.storsimple.com/





Configuration logicielle Les versions et paramètres logiciels utilisés pour les différents serveurs sont indiqués dans le tableau (iv)

ci-après.

Rôle d’ordinateur

Logiciels Modifications supplémentaires

Serveurs Web frontaux et serveurs d’applications

Windows Server® 2008 R2 Entreprise x64

Microsoft SharePoint Server 2010

RBS.msi a été installé à partir de SQL Server 2008 R2 Feature Pack.

Tous les correctifs Windows Server les plus récents ont été appliqués.

Serveur de bases de données

Windows Server 2008 R2 Entreprise x64

SQL Server 2008 R2 Enterprise x64

les correctifs Windows Server les plus

récents ont été appliqués..

Les modifications suivantes ont été

apportées aux paramètres du serveur

de bases de données :

- Mémoire maximum du serveur =

12 Go

- 4 fichiers de données tempdb ont

été créés et déplacés vers leur

propre volume.

Tableau (ii) – Configuration logicielle

Résultats des tests et observations Cette section récapitule les résultats des tests qui mesurent l’impact de l’utilisation du stockage BLOB

distant pour externaliser le contenu BLOB sur les différents attributs d’un déploiement SharePoint

Server 2010 et permet de répondre aux questions répertoriées dans le tableau (v) ci-après.

Description du test

1 Impact du stockage BLOB distant sur la taille de la base de données

2 Impact du stockage BLOB distant sur la taille de la sauvegarde des bases de données

3 Impact du stockage BLOB distant sur les durées de la sauvegarde et de la restauration

4 Impact du stockage BLOB distant sur les performances de la reconstruction des index

5 Impact du stockage BLOB distant sur les temps de réponse des transactions SharePoint

6 Impact du stockage BLOB distant sur l’opération d’analyse

7 Impact du stockage BLOB distant sur le transfert de fichiers suivant différentes tailles de

fichier

8 Durée requise pour la migration des données depuis et vers le magasin RBS

Tableau (v) – Scénarios des tests





1. Impact du stockage BLOB distant sur la taille de la base de données SQL Server Comme expliqué dans la section relative au stockage BLOB distant, la majorité des données de la base de

données SQL Server correspond à des données BLOB SharePoint. Dans la plupart des déploiements

SharePoint réalisés par les clients, notamment les déploiements utilisant SharePoint pour la collaboration et

la gestion des enregistrements, les données BLOB représentent plus de 95 % de la taille de la base de

données. Suivant la taille de la base de données, la quantité de données peut facilement s’élever à

plusieurs centaines de gigaoctets. Bien que possible en théorie, cela pose de nombreux défis et constitue

souvent un facteur limitant pour l’utilisationde SharePoint Server, l’évolutivité de la solution et l’utilisation

de certaines fonctionnalités bénéfiques telles que les Corbeilles.

Dans les tests dont les résultats sont récapitulés dans cette section, nous avons mesuré la taille de la base

de données, des fichiers de données et du fichier journal de transactions pour des bases de données de

contenu SharePoint de 100 Go composées de 100 000 objets et pour une base de données de contenu

SharePoint de 1 To composée de 2 millions d’objets avec et sans la fonctionnalité RBS. Les tailles de fichier

de chaque base de données sont indiquées dans le tableau (vi).

Taille (Go) Réduction

Sans RBS Avec RBS

Taille de la base de données (100 Go) 217.2 7.0 96.8%

Taille du fichier de données de la base de

données (100 Go) 106.9 3.2 97.0%

Taille du fichier journal de transactions de la

base de données (100 Go) 111.6 3.8 96.6%

Taille des données externalisées RBS -- 96.2 --

Taille de la base de données (1 To) 2,292 26 98.9%

Taille du fichier de données de la base de

données (1 To) 1,120 6.5 99.4%

Taille du fichier journal de transactions de la

base de données (1 To) 1,173 20 98.3%

Taille des données externalisées RBS -- 1,115 --

Tableau (vi) – Tailles des bases de données et des fichiers





Figure (iv) – Tailles des bases de données et des fichiers

Comme illustré dans la figure (iv) ci-dessus, sans la fonctionnalité RBS, la taille globale des bases de

données après téléchargement dans celles-ci de 100 Go et de 1 To de contenu SharePoint s’élève

respectivement à 217,2 Go et 2,29 To. Dans le cas de la base de données comportant 100 Go de contenu

SharePoint, 106,9 Go correspondent aux données réelles de la base de données, tandis que les 111,6 Go

restants correspondent au journal des transactions de la base de données. De même, pour la base de

données comportant 1 To de contenu SharePoint, 1,12 To correspond à la base de données, tandis que

1,2 To correspond au journal des transactions de la base de données. Lorsque la fonctionnalité RBS est

activée, la taille de la base de données de contenu de 100 Go est réduite de 96,8 %, tandis que la taille de

la base de données de contenu de 1 To est réduite de 98,9 %. Les tailles des fichiers de données et des

fichiers journaux de transactions sont réduites dans des proportions similaires.

Bien que l’espace supplémentaire requis pour le stockage des objets BLOB dans la base de données soit

souvent évident et bien compris, un inconvénient moins connu et encore moins compris est le défi lié à la

croissance du fichier journal de transactions SQL Server. Cette croissance est liée au fait que SQL Server

est une base de données cohérente transactionnellement, offrant des propriétés complètes d’atomicité, de

cohérence, d’isolation et de durabilité (ACID, Atomicity, Consistency, Isolation, Durability). Cela suggère

que chaque transaction est couronnée de succès ou qu’elle se solde par un échec ; il n’existe pas d’état

intermédiaire. SQL Server implémente les propriétés ACID en journalisant entièrement chaque opération

dans le journal de transactions de la base de données, en utilisant l’accès disque en écriture directe avant

que l’opération ne soit validée. Les propriétés ACID s’appliquent à la totalité des données et des types de

données SQL Server, objets BLOB compris. Aucun mécanisme ne permet de désactiver ou de court-

circuiter ce dispositif. Comme on peut s’y attendre, lorsque les objets BLOB SharePoint sont stockés dans

la base de données SQL Server, ils sont écrits deux fois, une première fois dans le journal des transactions,

puis une seconde fois dans le fichier de la base de données, comme l’indique la taille de la base de données

(2,29 To) utilisée pour le stockage de 1 To de contenu utilisateur. Ce fichier journal est tronqué lorsque la

sauvegarde de la base de données est exécutée et que l’option « Tronquer le journal » est sélectionnée.





Lorsque la fonctionnalité RBS est utilisée pour externaliser le contenu BLOB, les données BLOB sont écrites

dans le magasin BLOB avant que l’opération SharePoint ne soit validée. Par conséquent, les propriétés

ACID de l’opération sont indirectement réalisées sans la charge liée à la double écriture dans le journal des

transactions. L’ampleur de la réduction des fichiers de données de la base de données et des fichiers

journaux de transactions dépend de la taille des données et de la fréquence à laquelle vous tronquez le

journal des transactions pendant une sauvegarde.

Le contenu BLOB externalisé est stocké sur un partage de fichiers centralisé accessible à tous les serveurs

d’applications et serveurs Web frontaux SharePoint. Le volume de ce partage de fichiers peut se trouver

sur le serveur de bases de données ou sur un autre serveur. La figure (v) illustre les propriétés du partage

de fichiers utilisé dans les tests d’évaluation.

Remarque : étant donné que la fonctionnalité RBS réduit la taille de la base de données en déplaçant les

données BLOB vers le stockage externe, il est important de garder à l’esprit que l’espace disque global

consommé par les données BLOB n’est pas réduit. Bien sûr, les fournisseurs de solutions de stockage

peuvent intervenir à cet égard en utilisant des technologies propriétaires, telles que la déduplication, qui

permettent de réduire éventuellement l’espace disque. Les objets BLOB ne sont pas automatiquement

supprimés du magasin RBS lorsque le contenu correspondant est supprimé de SharePoint ; un cycle de

garbage collection distinct utilisant le travail du chargé de maintenance RBS intégré est requis pour que

soit définitivement supprimés les objets BLOB orphelins.

2. Impact du stockage BLOB distant sur la taille de la sauvegarde des bases de données Dans les tests dont les résultats sont récapitulés dans cette section, nous avons mesuré l’impact du

stockage BLOB distant sur la taille de la sauvegarde d’une base de données de contenu SharePoint de

100 Go composée de 100 000 objets, ainsi que d’une base de données de contenu SharePoint de 1 To

composée de 2 millions d’objets. Les tests et l’analyse ne comprenaient pas le magasin RBS. En d’autres

termes, les techniques et les durées liées à la sauvegarde et à la restauration des données BLOB résidant

sur le stockage RBS n’entrent pas dans le cadre de ce livre blanc.

Figure (v) – Taille du volume du partage de fichiers RBS





La commande Transact-SQL suivante a été utilisée pour l’exécution de la sauvegarde.

BACKUP DATABASE [WSS_Content] TO DISK = N'O:\WSS_Content' WITH NOFORMAT, INIT, NAME =

N'WSS_Content-Full Database Backup', SKIP, NOREWIND, NOUNLOAD;

Des tests ont également été effectués pour mesurer l’impact de la fonctionnalité de compression de

sauvegarde SQL Server2sur la taille de la sauvegarde avec et sans la fonctionnalité RBS. Les résultats des

tests sont récapitulés dans le tableau (vii) ci-après.

Taille (Go) Réduction

Sans RBS Avec RBS

Taille du fichier de données de la base de données (100 Go) 106.9 3.2 97.0%

Taille de la sauvegarde SQL Server (100 Go) 107.0 3.3 96.9%

Taille de la sauvegarde SQL Server avec compression (100 Go) 71.5 0.7 99.1%

Taille du magasin BLOB (100 Go) 0 96.2 --

Taille du fichier de données de la base de données (1 To) 1120 6.5 99.4%

Taille de la sauvegarde SQL Server (1 To) 1,119.0 6.6 99.4%

Taille de la sauvegarde SQL Server avec compression

(1 To) 1,046.0 1.2 99.9%

Taille du magasin BLOB (1 To) 0 1115 --

Tableau (vii) – Tailles des bases de données et des sauvegardes

2La compression des sauvegardes de base de données nécessite le recours à SQL Server Enterprise. Cette

fonctionnalité n’est pas disponible dans SQL Server Standard ou SQL Server Express.





Figure (vi) – Tailles des bases de données et des sauvegardes

Comme le montrent le graphique et le tableau ci-dessus, la taille de la sauvegarde de la base de données

comportant 100 Go de contenu est réduite de 96,9 % (107 Go contre 3,3 Go), tandis que la taille de la

sauvegarde de la base de données comportant 1 To de contenu est réduite de 99,4 % (1 119 Go contre

6,6 Go) lorsque la fonctionnalité RBS est activée. La taille des objets BLOB externalisés depuis la base de

données comportant 100 Go de contenu s’élève à 96,2 Go, tandis que la taille des objets BLOB externalisés

depuis la base de données comportant 1 To de contenu s’élève à 1 115 Go.

Lorsque la fonctionnalité de compression de sauvegarde SQL Server est activée sur la base de données, la

taille des sauvegardes est davantage réduite, atteignant 71,5 Go et 1 046 Go respectivement sans la

fonctionnalité RBS, et 0,7 Go et 1,2 Go avec la fonctionnalité RBS. Notez que la compression de la

sauvegarde s’avère efficace pour la réduction d’espace lorsque la fonctionnalité RBS n’est pas utilisée, car

SharePoint Server stocke les données BLOB conjointement avec les autres données (métadonnées). Si un

administrateur décide de stocker les objets BLOB séparément, la compression de la sauvegarde n’a aucun

effet dans la mesure où les objets BLOB stockés de la sorte ne sont pas compressés. Bien que cela soit un

avantage dans ce cas, la contrepartie est une plage de travail plus grande et une dégradation de l’efficacité

du cache, avec à la clé une réduction des performances.

Dans la mesure où les objets BLOB SharePoint sont immuables, c’est-à-dire qu’ils ne changent jamais une

fois créés, le contenu BLOB peut être sauvegardé à tout moment une fois que la sauvegarde de la base de

données SQL Server a été réalisée. Cela permet de réaliser à un moment donné une sauvegarde rapide et

cohérente transactionnellement de la base de données SQL Server, puis de sauvegarder le volume du

magasin BLOB ultérieurement. La sauvegarde SQL Server et la sauvegarde du magasin de contenu RBS

constituent un jeu de sauvegarde complet du contenu SharePoint. Une fois réalisé, le jeu de sauvegarde

permet de restaurer la base de données SharePoint dans l’état dans lequel elle se trouvait au démarrage

de la sauvegarde SQL Server.Remarque : lors de la planification d’une stratégie de sauvegarde et de

restauration qui implique le stockage de données RBS, planifiez le temps de récupération du stockage

BLOB distant. Tant que le stockage BLOB distant n’est pas restauré, les documents SharePoint ne sont pas

disponibles.





3. Impact du stockage BLOB distant sur les durées de la sauvegarde et de la restauration Dans les tests dont les résultats sont récapitulés dans cette section, nous avons mesuré l’impact du

stockage BLOB distant sur la durée de la sauvegarde et de la restauration d’une base de données. Comme

dans la section précédente, nous avons utilisé une base de données de contenu SharePoint de 100 Go

composée de 100 000 objets. Une série de tests a constitué à mesurer la durée requise pour sauvegarder

et restaurer les bases de données, selon que la fonctionnalité RBS est activée ou désactivée. Les résultats

des tests sur la base de données de 100 Go sont récapitulés dans le tableau (viii) ci-après.

Opération Sans RBS Avec RBS Réduction

Taille du fichier de données de la base de données 106.9 3.2 97.0%

Durée de la sauvegarde de la base de données 2 490 secondes 38 secondes 98.5%

Durée de la restauration de la base de données 1 290 secondes 28 secondes 97.8%

Durée de la sauvegarde de la base de données

lorsque la compression de la sauvegarde est

activée

3 160 secondes 37 secondes 98.8%

Durée de la restauration de la base de données à

partir de la sauvegarde compressée

1 330 secondes 28 secondes 97.9%

Durée de la sauvegarde du magasin BLOB (capture

instantanée)

-- 14 secondes --

Durée de la restauration du magasin BLOB

(capture instantanée)

-- 28 secondes --

Durée de la sauvegarde du magasin BLOB

(commande de copie)

-- 2 578 secondes --

Durée de la restauration du magasin BLOB

(commande de copie)

-- 2 880 secondes --

Tableau (viii) – Durées de la sauvegarde et de la restauration pour la base de données de 100 Go





Figure (vii) – Durées de la sauvegarde et de la restauration pour le jeu de données de 100 GB

Pour les sauvegardes et les restaurations de base de données, la durée est linéairement proportionnelle à

la taille de la base de données. Étant donné que la taille de la base de données est sensiblement plus petite

lorsque la fonctionnalité RBS est activée, la durée diminue en conséquence, comme l’illustre la figure (vii).

Lorsque la fonctionnalité RBS est activée, la durée de la sauvegarde de la base de données est inférieure

de 98,5 % (2 490 secondes contre 38 secondes), tandis que la durée de la restauration de la base de

données est inférieure de 97,7 % (1 284 secondes contre 28 secondes). De même, la durée de la

sauvegarde de la base de données avec utilisation de la compression de sauvegarde SQL Server est

inférieure de 98,8 %, tandis que la durée de la restauration d’une base de données avec compression de

sauvegarde est inférieure de 97,9 %. La sauvegarde de la base de données avec compression de

sauvegarde prend 27 % plus de temps et consomme beaucoup plus de ressources serveur SQL Server en

raison du traitement supplémentaire lié à la compression des données. Les commandes utilisées pour la

sauvegarde et la restauration des bases de données furent les suivantes :

BACKUP DATABASE [WSS_Content] TO DISK = N'O:\WSS_Content' WITH NOFORMAT, INIT, NAME =

N'WSS_Content-Full Database Backup', SKIP, NOREWIND, NOUNLOAD;

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;

Lorsque le stockage BLOB distant est utilisé, le magasin RBS doit être sauvegardé séparément. Cette sauvegarde peut être réalisée de façon asynchrone et parallèlement à la sauvegarde de la base de données, à condition que la sauvegarde du magasin RBS soit initiée après le démarrage de la sauvegarde de la base de données. Différents mécanismes permettent de sauvegarder le magasin RBS. Dans nos tests,

nous avons mesuré la durée de la sauvegarde du magasin à l’aide d’un mécanisme de capture instantanée de disque ainsi que d’une copie de répertoire séquentielle simple. Pour le contenu de 100 Go, la durée de la





sauvegarde du magasin RBS à l’aide d’une capture instantanée de disque est de 14 secondes, contre

2 578 secondes à l’aide de la commande de copie.

Remarque : lorsque le fournisseur FILESTREAM est utilisé, SharePoint 2010 sauvegarde ou restaure automatiquement les données BLOB et les métadonnées. Lors de la restauration d’une base de données pour laquelle la fonctionnalité RBS est activée, le magasin BLOB doit également être restauré. La batterie de serveurs SharePoint n’est considérée comme étant entièrement restaurée et accessible qu’une fois que le magasin BLOB a été restauré. Pour le contenu de 100 Go, la durée de la restauration du magasin RBS est de 28 secondes lorsqu’un mécanisme de capture

instantanée de disque est utilisé, contre 2 880 secondes lors de l’utilisation de la commande de copie. Il convient de mentionner que le magasin RBS ne doit être restauré que s’il a été endommagé ou qu’il devient instable.

4. Impact du stockage BLOB distant sur les performances de la reconstruction des index L’une des caractéristiques de SharePoint Server est la fragmentation fréquente et poussée des tables de la

base de données SQL Server principale qui stockent le contenu BLOB. À de nombreux égards, cette

fragmentation répond à des spécifications conceptuelles et est tributaire de l’architecture de l’application

SharePoint et du modèle d’accès de la base de données SQL Server principale. Lorsque la base de données

est fragmentée, les pages qui sont contigües logiquement n’apparaissent pas contigües physiquement dans

le fichier de données. En outre, les pages de données étant rarement utilisées au maximum de leurs

capacités, un nombre plus élevé de pages à faible densité est nécessaire pour le stockage des données.

Ces deux facteurs entraînent une augmentation plus importante que nécessaire de la plage de travail, ce

qui peut aboutir à une dégradation des performances.

Rassurez-vous, SharePoint 2010 réduit automatiquement la fragmentation en exécutant trois règles de

l’analyseur d’intégrité SharePoint. Ces règles vérifient régulièrement la fragmentation des index et

exécutent la procédure stockée proc_DefragmentIndices pour défragmenter les index automatiquement.

Toutefois, gardez à l’esprit que ce processus est gourmand en ressources et que la totalité de la batterie de

serveurs SharePoint est indisponible pendant le processus de reconstruction des index. Les trois règles

sont les suivantes :

Des bases de données utilisées par SharePoint comportent des index fragmentés.

Une ou plusieurs bases de données d’analyse de recherche peuvent contenir des index fragmentés.

Une ou plusieurs bases de données de propriétés de recherche peuvent contenir des index

fragmentés.

L’externalisation des objets BLOB via la fonctionnalité RBS permet d’atténuer sensiblement ce problème,

car la reconstruction des index d’une base de données plus petite requiert moins de temps.

Pour mesurer l’impact de la reconstruction des index, nous avons exécuté une série de tests au cours

desquels une opération de reconstruction des index a été exécutée pour toutes les tables de la base de

données de contenu SharePoint. Bien que cela ne soit pas forcément représentatif du déploiement en

situation réelle dans lequel les index sont reconstruits lorsque cela est nécessaire, l’approche choisie a

permis de rendre le test déterministe et reproductible. Dans le cadre de ces tests, nous avons mesuré la

durée de la reconstruction des index pour les bases de données de contenu de 100 Go et de 1 To, selon

que la fonctionnalité RBS est activée ou désactivée. Nous avons également mesuré l’impact d’une





opération de reconstruction des index sur la disponibilité et sur les performances de la batterie de serveurs

SharePoint.

Sans RBS Avec RBS Réduction

Durée de la reconstruction des index pour

toutes les tables (100 Go)

120 s 4 s 96.7%

Durée de la reconstruction des index pour

toutes les tables (1 To)

600 s 146 s 75.7%

Tableau (x) – Fragmentation des bases de données

Comme le montre le tableau (x) ci-dessus, la durée de la reconstruction des index est inférieure de 96,7 %

(120 secondes contre 4 secondes), pour la base de données de 100 Go, et de 75,7 % (600 secondes

contre 146 secondes) pour la base de données de 1 To, lorsque la fonctionnalité RBS est activée. Dans la

mesure où l’application Web SharePoint est indisponible pendant la quasi-totalité de la durée de la

reconstruction des index, la réduction de la durée a un impact direct sur la disponibilité de l’application

SharePoint et autorise une exécution plus fréquente de l’opération de reconstruction des index, ce qui

permet d’obtenir des performances plus cohérentes.

Plusieurs tests ont été réalisés pour mesurer l’impact du test de la reconstruction des index sur une base

de données de 100 Go lorsque la fonctionnalité RBS n’est pas activée. La figure (viii) ci-après indique les

résultats d’un test de ce type dans lequel une charge de travail de transfert de document est simulée et

l’opération de reconstruction des index est exécutée pendant l’état stable.

Figure (viii) : impact de l’opération de reconstruction des index sur les performances

Comme le montre la figure, pendant une opération normale (6:28 à 6:56), le taux de transfert de fichiers

attendu s’élève en moyenne à 85 fichiers par seconde. À 6:56, une opération de reconstruction des index a

été exécutée, pendant 120 secondes. Pendant cette période, le taux de transfert de fichiers a chuté jusqu’à

une valeur proche de zéro, comme l’indique le graphique. Cela suggère que le jeu d’opérations utilisateur





exécutées pendant cette période est stoppé pendant 120 secondes au plus ou, pire encore, qu’il atteint une

limite de délai d’expiration entraînant l’affichage d’un message d’erreur sur l’écran de l’utilisateur final.

Étant donné que l’opération de reconstruction des index pendant que la fonctionnalité RBS est activée sur

la base de données ne dure que 4 secondes, la plage est trop petite pour que l’impact global soit

significatif. De fait, la baisse des performances était si mineure qu’elle était difficile à représenter sur le

graphique et qu’il a été décidé de ne pas l’y faire figurer. Bien que ce test ait été réalisé à l’aide d’un

transfert de fichiers en guise de charge de travail, l’impact sur la disponibilité de la batterie de serveurs

SharePoint est le même sur tous les types de transactions.

5. Impact du stockage BLOB distant sur les temps de réponse des transactions SharePoint Comme expliqué dans les sections ci-dessus, l’activation de la fonctionnalité RBS aboutit à la réduction des

bases de données de contenu SharePoint qui, à leur tour, ont besoin de moins de ressources sur le serveur

de bases de données SQL Server pour exécuter les requêtes. L’économie en ressources permet de traiter

les requêtes existantes plus rapidement et de prendre en charge davantage de requêtes.

Dans le test dont les résultats sont récapitulés dans cette section, nous avons mesuré l’impact de

l’activation de la fonctionnalité RBS sur les temps de réponse des transactions. Pour ce test, nous avons

utilisé la charge de travail de combinaison de transactions SharePoint complètes, décrite dans la section

Méthodologie des tests. Cette charge de travail a été exécutée sur 6 serveurs de pilotage de charge qui

simulaient une charge de 100 utilisateurs exécutant la transaction SharePoint toutes les 15 secondes en

moyenne. Chaque test a été exécuté de façon progressive pendant 5 minutes, puis de façon continue

pendant 2 heures. Les temps de réponse moyens ont été mesurés pendant la totalité de la période de

2 heures d’exécution du test en état stable. Les résultats généraux obtenus sont indiqués dans le tableau

(xi) ci-après.

Mesure Sans RBS Avec RBS Réduction

Charge utilisateur maximale 100 100 0.0%

Demandes/s 84 84.3 -0.4%

Demandes ayant échoué 0 0 0.0%

Temps de réponse moyen 28 ms 21 ms 25.0%

Tests/s 6.4 6.42 -0.3%

Temps de réponse moyen de la page 210 ms 160 ms 23.8%

Tableau (xi) – Mesures des tests des temps de réponse des transactions

Le temps de réponse moyen dans toutes les transactions est inférieur de 25 % (28 millisecondes contre

21 millisecondes) lorsque la fonctionnalité RBS est activée sur la base de données de contenu. Cela

suggère que lorsque la fonctionnalité RBS est activée, les temps de réponse utilisateur final moyens des

transactions SharePoint sont 25 % plus rapides dans les différentes transactions. Étant donné que la

productivité et la satisfaction des utilisateurs SharePoint sont souvent tributaires des temps de réponse des

transactions SharePoint, une réduction de 25 % aboutirait à des niveaux de productivité et satisfaction plus

élevés.





Le tableau (xii) ci-après détaille les temps de réponse de chacune des quatorze transactions utilisateur

final.

Transaction % de la

transaction

Temps de réponse moyen de la transaction (s)

Réduction

Sans RBS Avec RBS

Page Site Mon site publique 16.0% 0.14 0.08 42.9%

Page d’accueil 25.0% 0.43 0.22 48.8%

Flux de travail de page 1.1% 109.00 109.00 0.0%

Créer une page 6.0% 15.72 15.67 0.3%

Créer un site de publication 1.0% 13.00 12.70 2.3%

Créer un site d’équipe 1.0% 17.90 18.30 -2.2%

Télécharger un document 12.2% 4.03 4.03 0.0%

Modifier le profil du site Mon site 6.9% 29.84 29.90 -0.2%

Grande page 10.1% 0.12 0.09 25.0%

Requête de recherche 14.8% 60.00 60.10 -0.2%

Gestionnaire de site 1.0% 0.45 0.31 31.1%

Transférer des documents 4.9% 30.20 30.50 -1.0%

Tableau (xii) – Temps de réponse des transactions





Figure (ix) – Temps de réponse des transactions

Comme indiqué ci-dessus, les temps de réponse moyens de 8 des 12 transactions sont égaux ou meilleurs

lorsque la fonctionnalité RBS est activée, quatre des transactions affichant une amélioration proche de

50 %. Pour les deux transactions affichant une diminution des performances, celle-ci est inférieure à

2,2 %, ce qui passerait probablement inaperçu en situation réelle. En général, lorsque la fonctionnalité RBS

est activée, il est probable que les performances s’améliorent pour les fichiers volumineux, notamment

dans le cas des systèmes tributaires des opérations d’E/S, par exemple lorsque celles-ci sont redirigées à

partir de la base de données SQL Server. Dans le cas des fichiers plus petits, il peut y avoir une

dégradation relative des performances, car le serveur Web frontal doit émettre deux demandes, au lieu

d’une, sur le réseau. Toutefois, il est probable que l’augmentation relative ne soit pas perceptible, même si

la différence de pourcentage est élevée, dans la mesure où les temps d’accès aux fichiers sont négligeables

au départ.

6. Impact du stockage BLOB distant sur les performances d’analyse La recherche constitue une partie intégrante de la plupart des déploiements SharePoint et l’un des services

SharePoint les plus gourmands en ressources. Dans de nombreux déploiements en entreprise, un

pourcentage élevé d’utilisateurs a accès aux données en naviguant depuis le portail de recherche plutôt

qu’en bénéficiant d’un accès direct au site ou au document. Face à ce comportement qui aboutit à une

utilisation intensive de la recherche, il est naturel que de nombreux clients fassent valoir que la recherche

est devenue le consommateur de ressources n° 1 ou qu’elle constitue souvent un goulot d’étranglement.





La recherche SharePoint Server comprend deux composants : l’analyse de recherche et la requête de

recherche. Dans le processus d’analyse de recherche, les robots analysent le corpus de recherche et

construisent (ou mettent à jour) l’index de recherche. L’index de recherche SharePoint se compose de deux

parties : une base de données de recherche et un fichier d’index de recherche plat. Les requêtes de

recherche, pour leur part, utilisent la base de données et l’index de recherche pour retourner les résultats

des requêtes de recherche des utilisateurs.

Dans les tests dont les résultats sont récapitulés dans cette section, nous avons mesuré la durée de

l’analyse du corpus de recherche via un serveur d’applications unique en utilisant les paramètres de

recherche par défaut. Les résultats de la durée de l’analyse avec et sans la fonctionnalité RBS sont

récapitulés dans le tableau (xiii) ci-après. Les résultats des requêtes de recherche ayant été récapitulés

dans la section précédente, ils ne sont pas répétés ici.

Opération Nb d’objets Sans RBS Avec RBS Réduction

Analyse de

recherche

complète

503,206 150 minutes 146 minutes 2.7%

Tableau (xiii) – Durées des analyses de recherche

Figure (x) – Résumé de l’analyse de recherche complète

Comme l’indiquent les résultats ci-dessus, l’activation de la fonctionnalité RBS sur les bases de données du

corpus de recherche a un impact très négligeable sur les performances, qui ne sont améliorées que de

2,7 %. Cela est conforme à nos attentes, car le traitement réalisé dans les deux cas est

approximativement le même.

7. Impact du stockage BLOB distant sur les performances de transfert La durée du transfert de fichiers volumineux vers SharePoint Server est souvent un facteur inhibant pour

les utilisateurs qui transfèrent de grandes quantités de contenu. Le grief le plus fréquent est que la copie

d’un fichier vers un partage de fichiers Windows est souvent beaucoup plus rapide que le transfert du

même fichier vers SharePoint Server. En effet, par défaut, tout le contenu du fichier est stocké dans la





base de données SQL Server, ce qui entraîne une charge supplémentaire. En outre, comme la base de

données SQL Server fonctionne selon un modèle cohérent transactionnellement, elle journalise d’office la

totalité de l’objet BLOB dans le journal des transactions SQL Server, en plus de stocker elle-même la copie

réelle de ce dernier, ce qui se traduit par un doublement de la charge des opérations d’E/S sur le système.

La fonctionnalité RBS accroît sensiblement les performances des transferts de fichiers volumineux, car elle

externalise l’objet BLOB directement depuis le serveur Web frontal, ce qui réduit au minimum la charge des

opérations d’E/S sur le système SQL Server.

Dans les tests dont les résultats sont récapitulés dans cette section, nous avons modélisé le déploiement

d’une gestion d’actifs numériques SharePoint et mesuré les performances du transfert de fichiers

volumineux allant de 1 Mo à 1,99 Go, selon que la fonctionnalité RBS est activée ou désactivée. Les

résultats de la durée du transfert des fichiers avec et sans la fonctionnalité RBS sont indiqués dans le

tableau (xiv) ci-après.

Taille du fichier

Durée du transfert du fichier

(secondes) Réduction

Sans RBS Avec RBS

1 Mo 1.2 1.0 16.7%

100 Mo 12.2 9.7 20.5%

500 Mo 55 28.8 47.6%

1 Go 69.4 48 30.8%

1,5 Go 138 71 48.6%

1,99 Go 178 87 51.1%

Tableau (xiv) – Durées des transferts des fichiers





Figure (xi) – Durées des transferts des fichiers

Comme l’indiquent le tableau et le graphique, la durée du transfert d’un fichier avec la fonctionnalité RBS

est 15 à 50 % plus rapide que lorsque la fonctionnalité RBS est désactivée. En termes absolus, cela signifie

que le transfert d’un fichier de 1,99 Go dure 87 secondes au lieu de 178 secondes, ce qui est significatif

dans le cas des utilisateurs qui transfèrent des fichiers vers un centre d’enregistrements compte tenu du

fait qu’ils attendent souvent face à leurs navigateurs Web que l’opération soit achevée pour poursuivre

leurs activités. Dans le cas d’une organisation qui comprend des centaines d’utilisateurs, effectuant chacun

des dizaines d’opérations de ce type, les gains de temps et les avantages s’accumulent rapidement et sont

particulièrement perceptibles lorsqu’un goulot d’étranglement affecte les ressources du serveur.

Des avantages similaires sont également liés aux opérations de téléchargement de fichier, bien que dans

ces opérations le système SQL Server et le serveur Web frontal SharePoint mettent en mémoire tampon

les données du fichier, ce qui se traduit par la consommation d’une quantité moindre de ressources sur le

stockage principal.

8. Durée requise pour la migration des données Une fois la fonctionnalité RBS activée sur une base de données, tous les fichiers transférés ou modifiés sont

automatiquement externalisés vers le magasin BLOB RBS associé au fournisseur actif. Les objets qui

étaient précédemment stockés dans la base de données demeurent dans celle-ci et continuent d’être

accessibles à partir de celle-ci ; ils ne sont pas automatiquement migrés vers le magasin RBS. Dans cette

configuration, SharePoint facilite l’accès transparent aux fichiers externalisés via la fonctionnalité RBS et

aux fichiers qui sont toujours stockés dans la base de données.

Bien que le mécanisme ci-dessus fonctionne correctement, à la longue, les utilisateurs peuvent souhaiter

migrer vers le magasin RBS externe la totalité du contenu existant stocké dans la base de données ou

migrer vers la base de données la totalité du contenu RBS externalisé. Ces deux opérations peuvent être





réalisées à l’aide de l’applet de commande Windows PowerShell™ 2.0 Migrate() fournie avec SharePoint

Server 2010. La séquence exacte des commandes Windows PowerShell à exécuter est indiquée dans le

script ci-après.

$cdb=Get-SPContentDatabase <nom de la base de données de contenu>

$rbss=$cdb.RemoteBlobStorageSettings

$rbss.GetProviderNames()

$rbss.SetActiveProviderName($rbss.GetProviderNames()[0])3

$rbss.Migrate()

Ces étapes doivent être exécutées pour chaque base de données vers laquelle vous souhaitez migrer les

objets BLOB. L’exécution du script Windows PowerShell lorsque le fournisseur de stockage BLOB distant est

activé entraîne la migration des objets BLOB depuis la base de données vers le magasin RBS, tandis que

l’exécution du script Windows PowerShell lorsque le fournisseur est désactivé se traduit par la migration

des objets BLOB vers la base de données.

Compte tenu du fait qu’une base de données de contenu peut comporter des milliers, voire des millions,

d’objets, soyez très attentif avant d’exécuter une migration des données, car celle-ci peut prendre

beaucoup de temps. Il est recommandé d’exécuter l’applet de commande Migrate() pendant des heures

creuses et à partir d’un serveur d’applications ou d’un serveur Web frontal SharePoint qui n’est pas utilisé

intensément.

Dans nos tests, nous avons exécuté le script ci-dessus à partir du serveur d’applications pour migrer

500 000 objets SharePoint d’une taille moyenne de 100 Ko vers et depuis la base de données. Les résultats

des tests sont récapitulés dans le tableau (xv) ci-après.

3Remarque : $rbss.GetProviderNames()[0]correspond au fournisseur de stockage BLOB distant

StorSimple.





Opération Durée

(minutes)

Nombre d’objets

BLOB migrés par

seconde

Migrer les données depuis la base de données de contenu

vers le magasin BLOB (externaliser les données)

243 34.3

Migrer les données depuis le magasin BLOB vers la base

de données de contenu (intégrer les données)

504 16.5

Tableau (xv) – Durées de migration des objets BLOB RBS

La durée supplémentaire nécessaire pour migrer les données vers la base de données de contenu est

imputable au traitement SharePoint Server et SQL Server complémentaire à effectuer sur le serveur

principal. Pour que les résultats soient comparables et conformes aux exigences du support Microsoft,

aucun paramétrage supplémentaire n’a été réalisé sur la base de données SQL Server hormis celui

mentionné dans la section relative à la configuration logicielle.

La méthode RBS Migrate peut être redémarrée de manière à lancer la migration des objets BLOB vers ou

depuis la base de données à partir de l’emplacement auquel elle s’était arrêtée lors de l’appel précédent.

Conclusion Dans ce document, nous avons vu dans quelle mesure l’utilisation de la fonctionnalité RBS permet de

diminuer la taille effective de la base de données de sauvegarde et de la base de données de contenu

SharePoint de plus de 95 %, réduisant ainsi la durée de la sauvegarde d’un pourcentage équivalent et

donnant la possibilité d’utiliser des solutions de stockage moins onéreuses pour stocker les données BLOB.

Nous avons également vu dans quelle mesure la fonctionnalité RBS permet aux utilisateurs de stocker des

fichiers multimédias volumineux dans SharePoint Server et de tirer pleinement parti de SharePoint Server

sans engendrer de goulot d’étranglement de la base de données SQL Server ou rendre la solution trop

onéreuse. Nous avons également analysé l’impact de la fonctionnalité RBS sur les durées des analyses de

recherche, les performances de la tâche de maintenance de reconstruction des index (améliorées de 96 %)

et les temps de réponse des transactions utilisateur final (réduits de 30 %, voire davantage pour certaines

transactions). Enfin, nous avons mesuré les performances des transferts de fichiers multimédias

volumineux spécifiques et la durée de la migration de données BLOB vers et depuis la base de données à

l’aide de la fonctionnalité RBS.

Globalement, il s’avère que l’utilisation de la fonctionnalité RBS facilite la maintenabilité d’une batterie de

serveurs SharePoint tout en améliorant l’évolutivité de la solution. Cela se traduit par une diminution des

coûts et par une amélioration de l’expérience de l’utilisateur final. Toutefois, lorsque la fonctionnalité RBS

est utilisée, les opérations de maintenance, telles que la sauvegarde du magasin BLOB, doivent être

attentivement planifiées et intégrées à la liste des tâches de maintenance.

Ressources supplémentaires Vue d’ensemble du stockage BLOB distant : http://technet.microsoft.com/fr-fr/library/ee748649.aspx

http://technet.microsoft.com/fr-fr/library/ee748649.aspx





Migrer du contenu dans RBS ou hors de RBS : http://technet.microsoft.com/fr-fr/library/ff628254.aspx

Optimiseur de base de données SharePoint StorSimple : http://www.storsimple.com/ (éventuellement en

anglais)

Tests de chargement de performances Microsoft Office SharePoint Server 2007 —

http://sptdatapop.codeplex.com/releases/view/1214#DownloadId=6918 (éventuellement en anglais)

Microsoft® SQL Server® 2008 R2 Feature Pack -

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=ceb4346f-657f-4d28-83f5-

aae0c5c83d52 (éventuellement en anglais)

À propos de StorSimple La solution de StorSimple résout les problèmes de stockage clés en termes de performances, d’évolutivité,

de facilité de gestion, de protection des données et de coût pour Microsoft SharePoint Server 2010.

StorSimple vous permet de manière unique de déployer un stockage de nouvelle génération sur site afin de

relever les défis actuellement liés aux applications avec la possibilité de tirer parti du stockage en mode

cloud public ou privé en temps voulu. Pour plus d’informations sur StorSimple, voir www.storsimple.com

(éventuellement en anglais).

À propos de Microsoft Microsoft Corporation est une entreprise multinationale ouverte basée à Redmond, Washington (États-Unis)

qui, par le biais de ses nombreuses divisions de produit, développe, crée, accorde sous licence et prend en

charge une large gamme de produits et de services essentiellement liés à l’informatique.

http://technet.microsoft.com/fr-fr/library/ff628254.aspx



http://sptdatapop.codeplex.com/releases/view/1214#DownloadId=6918

http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyID=ceb4346f-657f-4d28-83f5-aae0c5c83d52

http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyID=ceb4346f-657f-4d28-83f5-aae0c5c83d52



Documents

Performances du stockage BLOB distant SQL Server avec …download.microsoft.com/download/7/8/5/785A7616-BE9C-4978... · 2018. 10. 15. · Performances du stockage BLOB distant SQL