Introductiondownload.microsoft.com/download/7/8/5/785A7616-BE… · Web viewSharePoint Server 2010 offre une interface utilisateur plus rationalisée qui procure une expérience utilisateur

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

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

Burzin PatelStorSimple, Inc.

Peter ScharlockMicrosoft 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.

© 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

mailto:[email protected]?subject=Customer%20feedback:%20RBS%20white%20paper







Sommaire

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

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

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

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

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

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

Configuration logicielle.........................................................................................................................................11Ré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.........................................................................................................26Conclusion.......................................................................................................................................................................... 28Ressources supplémentaires..............................................................................................................................................28À propos de StorSimple......................................................................................................................................................29À propos de Microsoft.........................................................................................................................................................29






IntroductionAu 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 distantBLOB 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 RBSSharePoint 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 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 testsL’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.© 2011 Microsoft Corporation. Tous droits réservés. Page 7




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


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 testsNotre 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 travailLa 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 serveurLa 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érielleRôle d’ordinateur MatérielServeurs 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 stockageLa 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.

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:\

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.© 2011 Microsoft Corporation. Tous droits réservés. Page 11




http://www.storsimple.com/


Configuration logicielleLes 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 x64Microsoft SharePoint Server 2010RBS.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 x64SQL 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 observationsCette 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 ServerComme 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 RBSTaille 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 © 2011 Microsoft Corporation. Tous droits réservés. Page 14





(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éesDans 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 © 2011 Microsoft Corporation. Tous droits réservés. Page 15



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



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.

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 RBSTaille 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.© 2011 Microsoft Corporation. Tous droits réservés. Page 16





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.© 2011 Microsoft Corporation. Tous droits réservés. Page 17





3. Impact du stockage BLOB distant sur les durées de la sauvegarde et de la restaurationDans 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 GBPour 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 © 2011 Microsoft Corporation. Tous droits réservés. Page 19





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 indexL’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 © 2011 Microsoft Corporation. Tous droits réservés. Page 20





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 © 2011 Microsoft Corporation. Tous droits réservés. Page 21





é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 SharePointComme 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 © 2011 Microsoft Corporation. Tous droits réservés. Page 22





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’analyseLa 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 © 2011 Microsoft Corporation. Tous droits réservés. Page 24





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 transfertLa 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 fichierDurée du transfert du fichier

(secondes) RéductionSans 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éesUne 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.

ConclusionDans 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émentairesVue d’ensemble du stockage BLOB distant : http://technet.microsoft.com/fr-fr/library/ee748649.aspxMigrer du contenu dans RBS ou hors de RBS : http://technet.microsoft.com/fr-fr/library/ff628254.aspxOptimiseur 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 StorSimpleLa 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 MicrosoftMicrosoft 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://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

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

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



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

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

Documents

Introductiondownload.microsoft.com/download/7/8/5/785A7616-BE… · Web viewSharePoint Server 2010 offre une interface utilisateur plus rationalisée qui procure une expérience utilisateur