Embed Size (px)
Citation preview
Optimiser le Stockage SharePoint avec
l’Externalisation des données BLOB
Dan HolmeChief SharePoint Evangelist
Randy Williams Enterprise Trainer & Evangelist
Jeremy Thake Enterprise Architect
Contenus
Introduction 1
Principes de base 2
Documents, bases de données et BLOBs 2
Le défi de l’optimisation du stockage 2
Externalisation des BLOBs 3
EBS et RBS 3
Modules et fournisseurs 4
Parité fonctionnelle 4
Migration vers EBS ou RBS 5
Avantages 5
Réduction du coût de stockage 5
Règle des 80 pourcent 5
Stockage de document et de métadonnées 5
Versions de document 6
Contenus de corbeille 7
Cache des Office Web Apps 7
Bases de données de service 8
Journaux de transactions 9
Externalisation des BLOBs, capacité et coût 9
Optimisation de la Performance 10
Performance d’accès à un document unique 10
Performance des Bases de Données de contenu, du serveur SQL et de la ferme SharePoint 12
Amélioration de la gestion du stockage et Réduction de l’espace occupé 14
Restructuration de contenu efficace 15
Meilleure montée en charge 15
Considérations 16
Complexité architecturale accrue 16
Sauvegarde, Restauration, Haute Disponibilité et Plan de Reprise des Activités 16
Sauvegarde et Restauration Standard 17
Point de reprise et perte de données acceptable 17
Fenêtre de sauvegarde et objectif de temps de reprise 19
Haute disponibilité et Plan de Reprise d’Activité (PRA) 19
Options pour externaliser les BLOBs 20
Fonctionnalités d’externalisation des BLOBs 20
Prise en charge pour les versions et le stockage SharePoint 20
Sauvegarde, récupération, et récupération d’urgence 21
Prise en charge de cycle de vie du contenu 21
Examen des solutions tierces 22
1
Introduction
Quand les organisations font monter en puissance leur utilisation de SharePoint en tant que système
de gestion de contenu, intégrant la gestion de documents et d’enregistrements, la collaboration et
l’archivage, elles déplacent vers SharePoint des activités traditionnellement prises en charge par les
partages de fichiers et par les pièces jointes des emails. Au passage, la charge de stockage de ces
documents se déplace vers le stockage de SharePoint, c’est-à-dire les bases de données de contenu
SQL Server, souvent situées sur les ressources de stockage les plus performantes et coûteuses.
Les conséquences vont des plus évidentes (les coûts de stockage montent en flèche) aux plus contre-
intuitives (la performance de SharePoint peut être dégradée). Les organisations luttent pour définir pour
SharePoint une architecture de stockage optimisée, économique montant en charge et prête à recevoir
jusqu’à des téraoctets ou des dizaines de téraoctets (To) de contenu.
Il y a un débat dans les communautés SharePoint et SQL, entre les clients, experts et MVP, et même
chez Microsoft sur la capacité à monter en charge, sur l’impact des documents sur la capacité et la
performance du stockage, et sur le rôle de l’externalisation des données BLOB, qui permet de déplacer
les données BLOB (Binary Large OBject), les données non structurées qui représentent le contenu d’un
document, vers des niveaux de stockage plus économiques.
Ce qui a relancé le débat, c'est que Microsoft a mis à jour son guide pour le dimensionnement de
SharePoint en juillet 2011 pour prendre en charge les bases de données de contenu jusqu’à 4 To pour
les scénarios de collaboration, et celles de taille illimitée pour les archives de documents. Les nouvelles
recommandations de Microsoft incluent des directives pour l’architecture, les systèmes de stockage de
haute performance, la gouvernance et des outils de gestion complémentaires à ceux de SharePoint pour
offrir des niveaux de service (SLAs) en matière de performance, de sauvegarde et restauration et de
disponibilité.
Ce livre blanc explore les problématiques ainsi que les perspectives et recommandations liées à
l’externalisation des BLOBs.
Nous commencerons par étudier la configuration par défaut de SharePoint, par laquelle SharePoint
stocke le contenu d’un document comme un BLOB dans la base de données de contenu. Ensuite, nous
examinerons l’effet multiplicateur et surprenant d’un BLOB sur le stockage tout au long du cycle de vie
du document. Nous détaillerons ensuite les deux options que Microsoft a fournies pour l’externalisation
des BLOBs : EBS (External Blob Store) et RBS (Remote Blob Store).
Le reste du livre blanc explorera en détail les avantages potentiels de l’externalisation des BLOB,
notamment:
Réduction des coûts de stockage
Optimisation des performances
Amélioration de la gestion et diminution de l’empreinte du stockage
Restructuration efficace du contenu
Meilleure montée en charge
Enfin, nous regarderons les inconvénients potentiels de l’externalisation des BLOBs : la complexité
2
accrue de l’architecture et, en particulier, les considérations à en compte pour la sauvegarde, la restau-
ration, la haute disponibilité et la reprise sur sinistre.
Ce livre blanc est la première ressource d'une série sur l'optimisation et la gestion du stockage à être
publiée par une équipe de MVP SharePoint. Ce livre blanc a pour ambition de fournir un panorama
global et objectif des concepts et problèmes, et de vous donner les éléments pour comprendre, pour
partager avec vos pairs et votre hiérarchie et pour prendre des décisions éclairées sur le rôle de
l’externalisation des BLOBs dans votre architecture de stockage.
Commençons par examiner la configuration par défaut et les options de stockage des documents dans
SharePoint.
Documents, bases de données et BLOBs
Dans la plupart des organisations, SharePoint héberge des myriades de documents : fichiers au format
Office (Word, PowerPoint, Excel…), fichiers PDF, fichiers multimédias (images, podcasts, vidéos…) et
autres fichiers comme des cartes, spécifications techniques, documents numérisés…
Les utilisateurs téléchargent ou enregistrent les documents dans une ou plusieurs bibliothèques de
documents dans une collection de sites, ou les attachent aux éléments des listes. Par défaut, ces
documents sont stockés dans la base de données de contenu de la collection de sites contenant la liste
ou la bibliothèque de documents.
Dans la base de données de contenu, les métadonnées d’un document ou un élément de liste sont
stockées dans la table AllUserData. Si un document est stocké dans une bibliothèque, ou comme pièce
jointe, SharePoint conserve ses propres métadonnées sur le document dans la table AllDocs. Le contenu
du document est stocké dans un format de données non structurées nommé BLOB dans la table
AllDocStreams. Des identificateurs globaux uniques (GUID) sont utilisés pour lier les enregistrements
dans ces trois tables. Si le contrôle de version est activé, les métadonnées sur les versions du document
sont stockées dans la table AllDocVersions, et les versions du BLOB sont stockées dans AllDocStreams.
SQL Server est un serveur de base de données qui est optimisé pour la performance des données
structurées, relationnelles, où la taille des enregistrements est inférieure à 8 kilo-octets (Ko). Microsoft a
déplacé les BLOBs vers une table séparée pour optimiser la performance de SQL et donc de SharePoint.
D’un côté il y a une légère perte de performance à chaque ouverture ou enregistrement d’un document, parce
que SQL doit joindre AllUserData avec les autres tables avant de pouvoir accéder aux données binaires.
D’un autre côté, une myriade de processus qui dépendent des performances de SQL Server bénéficient
énormément de ce choix. Cette conception de la base de données de contenu en tables distinctes et liées
est au total un bénéfice net pour SharePoint.
Le défi de l’optimisation du stockage
L’infrastructure de stockage qui supporte un service SharePoint d’entreprise concerne de nombreux
interlocuteurs. Les architectes du stockage, les administrateurs de base de données, les administrateurs
SharePoint, les utilisateurs finaux de SharePoint, et les responsables fonctionnels sont tous concernés
Principes de base
3
par les capacités de l’infrastructure de stockage à être disponible, récupérable, performante,
administrable et économique.
La configuration standard de SharePoint place tous les contenus dans les bases de données de con-
tenu de SQL Server. Cela peut poser un problème de montée en charge. SQL Server est généralement
hébergé sur le stockage de niveau 1, le plus rapide, le plus riche en fonctionnalités et le plus coûteux.
Si tous les documents sont stockés dans SQL Server, le coût d’utilisation du stockage de niveau 1 pour
l’ensemble de la gestion de contenu de l’entreprise pourrait devenir prohibitif.
Au fil du temps, le problème augmente, parce qu’année après année, une implémentation typique de
SharePoint héberge des quantités croissantes de contenu, bien que la plupart des contenus soient
inactifs. Bien que le volume total de contenu augmente souvent de façon exponentielle, le volume de
données actives augmente souvent bien moins vite, de façon linéaire. Il en résulte que le stockage haut
de gamme de niveau 1 est utilisé en grande partie comme archivage pour des quantités de contenu
augmentant en flèche qui n’ont pas besoin de la performance ou des fonctionnalités du stockage de
niveau 1.
Vous pourriez penser que déplacer du contenu vers des niveaux de stockage moins chers pénaliserait
la performance. Même si c’était le cas, on pourrait optimiser le stockage en créant une architecture de
stockage hiérarchique dans laquelle les données moins importantes ou moins actives seraient déplacées
vers les niveaux de stockage moins chers, et au contraire, les données plus importantes ou plus actives
seraient conservées sur le stockage de niveau 1. Mais, comme vous le verrez plus tard dans ce livre
blanc, il est souvent possible de réduire le coût de stockage tout en augmentant la performance.
Externalisation des BLOBs
Dans les communautés SharePoint et SQL, certains considèrent que SharePoint n’aurait jamais dû être conçu pour stocker les documents en tant que BLOBs dans une base de données relationnelle comme SQL Server. En fait, la version 1.0 de SharePoint (SharePoint Portal Server 2001) utilisait Web Storage System et pas SQL Server. À partir de la version 2.0 de SharePoint (Windows SharePoint Services et SharePoint Portal Server 2003), le stockage a été déplacé vers SQL Server.
Ces dernières années, Microsoft a intégré à SharePoint et SQL Server des options pour sortir les BLOBs de SQL Server vers d’autres niveaux de stockage, en conservant les métadonnées dans la base de données de contenu avec des pointeurs vers les documents associés.
EBS et RBS
Dans SharePoint 2007 Service Pack 1 (SP1), Microsoft a introduit EBS (External Blob Storage). Dans SQL Server 2008, Microsoft a ajouté RBS (Remote Blob Storage). À très haut niveau, EBS et RBS exécutent la même tâche de base : ils permettent à SharePoint de stocker les BLOBs en dehors de la base de données SQL Server.
EBS fait partie du produit SharePoint, à partir de ses versions SharePoint 2007 Service Pack 1 et SharePoint 2010. SharePoint 2007 prend en charge l’externalisation des BLOBs uniquement avec EBS.
Dans SharePoint 2010, l’externalisation des BLOBs est prise en charge utilisant soit EBS soit RBS. Cependant, EBS a été déclaré obsolète et sera très probablement supprimé des futures versions de SharePoint au profit de RBS.
RBS peut être obtenu en téléchargeant le Feature Pack pour SQL Server 2008 R2 sur
4
http://go.microsoft.com/fwlink/?LinkID=177388. Cette version (ou une version plus récente) de RBS est obligatoire pour SharePoint 2010. Les composants serveur de RBS peuvent être installés sur SQL Server 2008 R2 ou sur SQL Server 2008 SP1. Les composants clients sont installés sur tous les serveurs Web frontaux SharePoint.
Modules et fournisseurs
EBS et RBS exigent des composants supplémentaires pour gérer la communication entre SharePoint et
l’emplacement choisi pour le stockage des BLOBs hors de SQL Server, (appelé magasin d’objets BLOB).
EBS utilise une infrastructure de plug-in qui exige un module tiers. RBS expose un ensemble d’interfaces
de programmation (API) sur lesquelles les développeurs et les éditeurs de logiciels indépendants
peuvent développer des fournisseurs. Un fournisseur est l’interface entre RBS et un type spécifique de
magasin d’objets BLOB.
Microsoft a créé le fournisseur FILESTREAM, qui est inclut gratuitement avec les fichiers d’installation
de RBS. Le fournisseur FILESTREAM permet d’externaliser les BLOBs vers le système de fichiers
local de SQL Server. Cela peut inclure le stockage attaché directement et les volumes SAN et NAS
attachés iSCSI, supposant que ces volumes répondent aux exigences de performances de stockage de
SharePoint d’au moins 0,25 opérations d’entrée/sortie par seconde (IOPS) et par gigaoctet (Go) stocké,
et pas plus de 20ms de temps d’accès au premier octet (TTFB : time-to-first-byte).
Bien que beaucoup de gens aient décrié la performance du fournisseur FILESTREAM, l’expérience
montre que sa performance est au moins aussi bonne qu’anticipé. Certains fournisseurs RBS d’éditeurs
de logiciels indépendants surpassent FILESTREAM, certains font moins bien. Un fournisseur RBS pour
une plate-forme de stockage dans le cloud, par exemple, sera à priori plus lent par la nature même du
stockage dans le cloud. Il est recommandé de tester les fournisseurs d’externalisation des BLOBs dans
votre environnement pour identifier les différences de performances et surtout pour déterminer si ces
différences ont un impact notable sur les performances globales de SharePoint.
Même en laissant la performance de côté, beaucoup d’organisations se tournent vers les fournisseurs
tiers pour leur support de diverses plates-formes de stockage et de règles métier pour l’externalisation,
les fonctionnalités d’administration, et la maintenance. Les éditeurs de logiciels ont créé des fournisseurs
pour des magasins d’objets BLOB dans les dossiers partagés sur un serveur distant, sur les plates-
formes de stockage dans le cloud, et sur des plates-formes spécifiques NAS et SAN. Les solutions de
stockage tierces fournissent différents niveaux de gestion de BLOBs basés sur des règles, afin qu’une
organisation puisse spécifier quels types de BLOBs sont ou ne sont pas externalisés et ainsi créer
une plate-forme de gestion du stockage hiérarchisé. L’installation et la configuration de fournisseurs
RBS tiers proposent généralement une meilleure expérience qu’avec le fournisseur FILESTREAM. Les
tâches de maintenance sont généralement automatisées. Et les éditeurs tiers proposent généralement
des fonctionnalités d’analyse et de rapport. De telles fonctionnalités ont un coût, bien sûr, qui doit aussi
être pris en compte. Plus loin dans ce livre blanc, nous discuterons des fonctionnalités de ces solutions
tierces d’externalisation des BLOBs.
Parité fonctionnelle
Il est important de remarquer que l’externalisation des BLOBs est transparente pour le reste de
SharePoint. SharePoint considère les BLOBs comme faisant partie de son référentiel de contenu, où que
soit physiquement situé le contenu.
5
Donc, que les BLOBs soient stockés dans une base de données de contenu ou externalisés, SharePoint
gère les autorisations pour le contenu et continue à l’indexer. Toutes les fonctionnalités de gestion de
documents SharePoint, y compris l’extraction et contrôle de versions, continuent à être disponibles.
Aucune des fonctionnalités de SharePoint n’est modifiée lors de l’externalisation des BLOBs.
Migration vers EBS ou RBS
Vous pouvez activer EBS ou RBS à tout moment. Vous pouvez aussi modifier les règles qui définissent
quels BLOBs sont externalisés quand vous le souhaitez. Il y a des outils (Windows PowerShell dans le
cas de RBS) pour analyser la base de données de contenu et déplacer du contenu vers le magasin
d’objets BLOB.
Les sections suivantes examineront les bénéfices et les questions à prendre en compte lors de la mise
en œuvre d’une infrastructure de stockage optimisé pour SharePoint. Comme EBS et RBS présentent
des avantages et des défis similaires, nous nous référerons en général aux solutions d’externalisation des
BLOBs.
L’externalisation des BLOBs peut procurer des avantages significatifs dans de nombreux domaines:
réduction des coûts, amélioration des performances, meilleure gestion du stockage, réduction de
l’espace occupé, restructuration du contenu et meilleure montée en charge.
Réduction du coût de stockage
La première et la plus évidente considération relative à l’optimisation du stockage est le coût, qui est lié
directement à la capacité et au(x) niveau(x) de stockage qui héberge(nt) le contenu SharePoint. Mais
dans quelle mesure les BLOBs influent-ils sur la capacité ainsi que les coûts ? La réponse pourrait vous
surprendre.
Règle des 80 pourcent
Dans une base de données de contenu typique, les documents (métadonnées et BLOBs) ont tendance à
consommer la majorité de l’espace. Les bases de données de contenu ploient sous le poids des BLOBs.
Jusqu’à 80 pourcent des données d’un déploiement typique de SharePoint Foundation sont des fichiers
stockés en tant que données BLOB. Ces objets BLOB comprennent les données associées aux fichiers
SharePoint.
http://msdn.microsoft.com/fr-fr/library/bb802976.aspx
Cependant, cette “règle des 80 pourcent” ne dit pas toute la vérité. Ce que cette estimation de 80
pourcent n’illustre pas, c’est l'ampleur de l'impact du stockage BLOB. Dans un environnement typique
de collaboration, un document est souvent stocké plusieurs fois : l’espace requis pour son stockage est
significativement supérieur à ce à quoi vous vous attendriez. Examinons l’impact total d’un document et
de son stockage BLOB tout au long de son cycle de vie.
Stockage de document et de métadonnées
SharePoint prend en charge les documents jusqu'à une taille de 2 Go
Avantages
6
(http://technet.microsoft.com/fr-fr/library/cc262787.aspx#ListLibrary), une limite logicielle qui résulte du
pointeur 32 bits utilisé dans SQL Server. Il n’y a aucun moyen de dépasser cette limite et de stocker des
documents plus volumineux dans une base de données de contenu – avec ou sans externalisation des
BLOBs.
SharePoint inclut une limitation de la taille des fichiers téléchargés qui est configurable par application
web. La taille maximale par défaut est de 50 mégaoctets (Mo) —nettement inférieure à la limite
maximum de 2 Go.
Cette valeur basse reflète des problématiques pratiques comme la performance du réseau, la
performance du transfert de fichiers volumineux sur HTTP et les attentes des utilisateurs pour la
performance de transfert de fichiers. Beaucoup d’organisations conservent cette limite par défaut,
certaines décident de la relever. Si vous choisissez de relever la taille maximale de téléchargement,
faites-le lentement et après des tests minutieux.
Chaque document d’une bibliothèque SharePoint dispose de métadonnées associées. Certaines
métadonnées sont configurées par l'utilisateur, comme certaines colonnes des bibliothèques.
D’autres métadonnées sont utilisées en interne par SharePoint. La quantité de métadonnées associées à
un document varie principalement en fonction des métadonnées configurées par l’utilisateur.
Il est facile de comprendre que les scénarios avec des documents plus volumineux ont une proportion
de BLOBs plus importante par rapport aux métadonnées, et inversement les scénarios avec des
documents plus petits et plus de métadonnées ont cette même proportion plus faible. L’estimation de 80
pourcent est basée sur une moyenne de nombreux environnements SharePoint. Mais il y a un hic : un
document est rarement, voire jamais, stocké une seule fois.
Versions de document
Quand l’historique des versions est activé pour une bibliothèque de documents, toute modification
apportée à un document ou à ses métadonnées entraîne l’utilisation de stockage supplémentaire. Deux
points sont souvent mal compris et ont un impact significatif sur le stockage lorsque le contrôle de
version est activé :
1. Aucune compression différentielle n’est utilisée dans SharePoint. Quand une nouvelle version
est enregistrée, l’espace de stockage utilisé est la taille totale du fichier (et pas juste les différences ou
incréments entre les versions). Pour faire simple, deux versions d’un document avec des modifications
mineures occupent deux fois la taille du document et de ses métadonnées.
2. Une nouvelle version de document est créée dès que le document – ou ses
métadonnées- est modifié. Si un document est téléchargé sur une bibliothèque et n’est jamais
modifié, mais que ses métadonnées sont modifiées cinq fois au cours d'un mois, le stockage occupé
par ce document est approximativement cinq fois la taille du document et de ses métadonnées.
Quand le contrôle de version est activé, l’impact d’un document sur le stockage est multiplié par le
nombre de versions de ce document.
Ainsi, il est important de définir des limites pour l’historique des versions – la rétention de versions
illimitées peut mener au gonflement significatif des bases de données.
7
Contenus de corbeille
Quand un document est supprimé, ce document et ses versions sont conservés selon les paramètres
de corbeille SharePoint de l’application web. Un utilisateur peut restaurer un document qu’il a supprimé
depuis la corbeille.
Quand un utilisateur vide la corbeille, le document et ses versions continuent d’être conservés, et
peuvent être restaurés par les administrateurs de la collection de sites, à partir de ce qui est nommé la
corbeille secondaire.
Chaque collection de sites dispose d’une corbeille. Toutefois, la corbeille dispose de deux paramètres
configurables au niveau de l’application web. Ces paramètres s’appliquent à toutes les corbeilles de
collection de sites d’une application web.
Le premier paramètre de corbeille spécifie le nombre de jours durant lesquels un document supprimé
sera conservé par la corbeille. Ce paramètre s’applique à partir du moment où le document est
supprimé.
Peu importe que le document soit dans la corbeille d’utilisateur ou dans la corbeille secondaire. X jours
après qu’un document a été supprimé originellement par l’utilisateur, il est supprimé de la corbeille et le
document est enlevé de la base de données de contenu.
Le deuxième paramètre applique un quota de stockage à la corbeille secondaire. Quand les éléments
sont déplacés dans la corbeille secondaire, ils sont limités par ce quota. Quand le quota a été atteint, les
éléments les plus anciens de la corbeille secondaire sont enlevés pour faire de la place aux éléments
nouvellement supprimés.
Le quota est configuré de façon relative au quota de la collection de sites. Donc, si une collection de
sites est limitée à 50 Go de quota, et la corbeille secondaire est limitée à 50 pourcent du quota, alors la
corbeille secondaire de cette collection de sites est effectivement plafonnée à 25 Go.
Par conséquent, l’analyse de l’impact du stockage d’un document (BLOB et métadonnées) sur la base
de données de contenu doit prendre en compte le fait que ce document et ses versions continuent à
affecter la base de données de contenu jusqu’à la purge d’un document de la corbeille secondaire.
Audit
Les activités auditées génèrent des entrées dans le journal d’audit. Le volume de stockage requis pour
l’audit peut être significatif, en particulier, si vous auditez tous les Affichages (view). Toutefois, la taille de
l’entrée d’audit et celle des journaux d’audit ne sont pas liées à la taille du document, ou au fait que les
BLOBs soient stockés dans SQL ou externalisés. Donc, même si vous devez prendre en compte l’audit
lors de l'estimation des besoins de stockage totaux pour une base de données de contenu
(http://technet.microsoft.com/fr-fr/library/cc298801.aspx#Section1), nous n’examinerons pas l’audit de façon
plus approfondie dans ce livre blanc.
Cache des Office Web Apps
Afin d’améliorer la performance de SharePoint quand les applications Web Microsoft Word et Microsoft
8
PowerPoint sont utilisées, celles-ci créent les vues des documents dans un cache appelé cache Office
Web Apps.
Quand un document est affiché, il peut être extrait du cache. Une vue d’un document est créée
uniquement si elle n’existe pas dans le cache, ou si le document a été modifié depuis le dernier affichage
stocké dans le cache. Une tâche du minuteur supprime les documents du cache après une période
d’expiration configurable.
Si une application Web SharePoint est associée aux applications Web Microsoft Word ou PowerPoint,
c’est la base de données de contenu qui contiendra le cache. Dans une application Web chargée en
documents, le cache peut devenir vraiment volumineux.
Par défaut, le cache est plafonné à 100 Go. Il est recommandé de configurer les Office Web Apps pour
utiliser une base de données de contenu dédiée au sein de l’application Web SharePoint, et de gérer la
taille du cache afin d’optimiser la performance et le stockage. Vous pourrez en savoir plus sur
http://technet.microsoft.com/fr-fr/library/ee837422.aspx.
La taille du cache Office Web Apps est la même que les BLOBs soient stockés dans SQL Server ou
externalisés. Elle est purement fonction du nombre et de la taille des documents, de la fréquence
d'accès à ces documents, et de la configuration de l’administrateur.
En conséquence, bien que le cache Office Web Apps doive être pris en compte pour l’estimation du
stockage requis pour une application Web, il n’impactera pas le stockage requis pour les autres bases
de données de contenu si il est cantonné dans une base de données dédiée.
Bases de données de service
Un document affecte indirectement le stockage requis par les applications de service. Par exemple,
l’accès à un document peut être suivi par l’application du service Web Analytics.
Marquer, commenter et évaluer les activités consomme approximativement 9 Ko par entrée dans la base
de données de marquage social du service de Profil Utilisateur.
Ces données sont relativement négligeables, et ne dépendent ni de l’emplacement des BLOBs (SQL
Server ou externalisé) ni de la taille du document.
Cependant, le service de recherche est affecté directement par le nombre de documents et par
leur taille. Les bases de données d’analyse, de propriétés, et les partitions d’index sont directement
impactées par le nombre et la taille des documents.
La planification de capacité pour la recherche est à la fois une science et un art, mais des estimations
approximatives à partir d’implémentations standard donnent autour de 20 pourcent de la taille totale du
contenu indexé (le corpus).
Donc, si vous indexez 1 To de contenu typique, vous pouvez compter approximativement sur 200 Go
d’utilisation de stockage par les bases de données de recherche et l’index. Pour plus d’informations,
veuillez consulter le site http://technet.microsoft.com/fr-fr/library/gg750251.aspx.
9
La taille de la base de données de recherche et d’autres services n’est pas impactée par l’externalisation
éventuelle des BLOBs.
Journaux de transactions
SQL Server enregistre toutes les activités dans le journal de transactions d’une base de données
avant de valider une transaction dans la portion de données de la base de données. Les journaux de
transactions croissent jusqu’à la sauvegarde de journal, lors de laquelle l’espace utilisé par le journal est
effacé, mais la taille du fichier ne diminue pas.
Vous pouvez réduire manuellement la taille d’un journal de transactions SharePoint. C’est utile si un
journal de transactions a été hors de contrôle, mais la meilleure pratique est de gérer la taille du journal
de transaction par la gestion de sauvegardes de journaux de transactions.
Quand un document est téléchargé ou modifié, le BLOB et les métadonnées sont d’abord écrits dans
le journal de transaction. Puis la transaction est validée dans les tableaux appropriés dans la base de
données de contenu elle-même.
Par conséquent, l'impact réel d’un document sur la taille de base de données de contenu totale, incluant
le journal de transactions, peut être approximativement calculé deux fois la taille du document multiplié
par le nombre de créations et de modifications de versions pendant l’intervalle entre les sauvegardes de
journal.
La taille du journal de transactions est directement liée au stockage des BLOBs. Si les BLOBs sont
externalisés et ne sont pas stockés dans la base de données de contenu, alors le BLOB n’est pas écrit
non plus dans le journal de transactions SQL Server.
Externalisation des BLOBs, capacité et coût
Comme vous le voyez, le stockage requis pour un seul document peut énormément varier, il se base
sur la rétention de versions, la modification du document ou de ses métadonnées, les paramètres des
applications Web comme la corbeille, les paramètres d’audit, l’utilisation d’Office Web Apps et d’autres
services, et même les stratégies de sauvegarde. Dans un scénario typique de collaboration intensive, un
document actif peut occuper un espace de stockage équivalent à plusieurs fois sa taille.
Le stockage des BLOBs dans la base de données de contenu peut être coûteux, aussi bien du point de
vue du coût fixe que du coût total de possession. Historiquement, beaucoup d’organisations stockent les
documents pour la collaboration sur des serveurs de fichier, qui sont relativement bon marché comparés
avec le stockage nécessaire à SQL Server pour SharePoint, typiquement de niveau 1 offrant des IOPS
très élevés. Le déplacement d’un tel contenu vers SharePoint et dans le stockage de niveau 1 peut
revenir très cher, surtout en prenant en compte le fait qu’un document peut nécessiter un espace de
stockage de plusieurs fois sa taille tout au long de son cycle de vie.
L’externalisation des BLOBs à proprement parler ne réduit pas l’espace de stockage total de votre
infrastructure SharePoint, sauf pour les journaux de transactions. Mais elle vous permet de transférer
la charge de stockage vers des niveaux plus économiques. Les économies de coûts peuvent être
énormes. Certaines organisations ont calculé des économies de dizaines de millions de dollars
10
(ou d’euros) par an grâce à l’optimisation du stockage concentrée sur l’externalisation des BLOBs. Et
certaines plates-formes de stockage disposent de fonctionnalités qui peuvent réduire l’encombrement
de stockage total de SharePoint, en combinaison avec l’externalisation des BLOBs. Ces fonctionnalités
seront abordées plus loin dans ce livre blanc.
Optimisation de la Performance
On pourrait penser qu’il faut déplacer tous les BLOBs vers les niveaux de stockage moins coûteux afin
de réduire le coût de stockage. Mais il vous faut aussi considérer l'impact de l’externalisation des BLOBs
sur la performance de SharePoint.
Par exemple, si vous utilisez un fournisseur tiers pour externaliser les BLOBs dans une plate-forme de
stockage dans le cloud, telle que Amazon ou Azure, il va de soi que les lectures et les écritures de
documents seront plus lentes que dans le stockage local de SQL Server.
Cependant, toutes les externalisations de BLOBs ne réduisent pas la performance. En fait, il est même
possible d’augmenter la performance par l’externalisation des BLOBs dans certains scénarios et
configurations.
La question est : Dans quels cas la performance de SharePoint est-elle améliorée avec l’externalisation
des BLOBs, et dans quels cas est-elle dégradée ?
La réponse à cette question exige un examen attentif de deux problèmes de performances :
La performance de l’accès en lecture et en écriture à un document unique
La performance de l’ensemble du service SharePoint, à travers toutes les collections de sites
d’une base de données de contenu et à travers tous les contenus hébergés dans SQL Server, dans
un scénario réel.
La plupart des informations publiées par la communauté SharePoint se concentre uniquement sur le
premier problème, ce qui est malheureusement incomplet et mène à des décisions qui sacrifient la
performance dans les vrais environnements de production.
Dans les sections suivantes, nous explorerons ces deux aspects de la performance. Cependant,
il est essentiel de se rappeler que la seule façon réelle pour connaître les performances de votre
environnement SharePoint avec ou sans l’externalisation des BLOBs est de le tester dans des scénarios
qui sont réalistes et représentatifs de votre environnement.
De plus, vous devez évaluer si la dégradation des performances est détectable par les utilisateurs,
et si elle empêche SharePoint de répondre à leurs besoins et aux SLAs liés à la performance. Enfin,
vous devez considérer chaque scénario que vous prenez en charge. Les utilisateurs peuvent trouver
acceptable que l’accès à un enregistrement archivé soit plus lent que l’accès aux documents sur
lesquels ils collaborent activement.
Performance d’accès à un document unique
La configuration standard de SharePoint stocke les BLOBs dans les bases de données de contenu
SharePoint. Cela offre une performance optimale dans certains scénarios.
11
Performance de stockage de niveau 1 – De nombreuses organisations réservent des sous-systèmes
de stockage de niveau 1 de haute performance pour SQL Server. La performance de la plate-forme
de stockage SQL Server affecte directement la performance de SharePoint. Les documents accédés à
partir d’un SAN à haute performance offriront de meilleures performances que les documents dont les
BLOBs auront été externalisés vers un stockage dans le cloud public.
Petits fichiers – quand un petit document est lu (ou modifié) dans une base de données de contenu, la
performance de cette activité unique est souvent optimale.
Fichiers lus fréquemment- Quand un petit document est accédé régulièrement en lecture, le cache
SQL peut améliorer encore la performance de l’accès à ce document. Un document accédé récemment
et mis en cache peut être récupéré de la mémoire cache, plutôt que du disque.
Il y a cependant un point à partir duquel les performances de SharePoint sont meilleures avec des
BLOBs externalisés, en fonction des scénarios.
Les lectures et les écritures d’un petit document unique peuvent être plus rapides quand il est stocké
dans SQL. La performance de lecture peut également être améliorée grâce au cache SQL. Mais quand
les fichiers se développent en taille ou sont accédés moins fréquemment, la performance peut être
améliorée par le stockage des BLOBs dans une plate-forme qui est mieux adaptée au stockage de
fichiers.
La performance en écriture atteint plus vite un point d’équilibre que celle de lecture car un BLOB doit
être écrit deux fois (dans le journal de transactions, puis dans la table de base de données). De plus, le
cache n’apporte aucun avantage pour un document nouveau ou modifié. L’augmentation de la taille des
documents pénalise l’enregistrement des BLOBs, enregistrés deux fois, et réduit la performance globale
des documents stockés dans une base de données de contenu.
Heureusement, RBS vous permet de spécifier un seuil de taille de fichier, à partir duquel les BLOBs des
documents sont externalisés, et en-dessous duquel les BLOBs restent stockés dans la base de données
de contenu. Les solutions basées sur EBS ainsi que les solutions tierces basées sur RBS peuvent
exploiter d’autres règles, par exemple le type de fichier, pour déterminer si un BLOB doit être externalisé
ou non.
Il n'existe aucune formule pour déterminer le seuil de taille de fichier à partir duquel la performance
est améliorée par l’externalisation des BLOBs. Il y a trop de facteurs dans l’équation de performance,
notamment les caractéristiques et la fréquence d’accès du document, et les caractéristiques de
performance de plates-formes de stockage sous-jacentes.
Nos tests ont montré que les BLOBs supérieurs à 1 Mo se comportent généralement mieux quand ils
sont externalisés (en supposant que les performances du magasin d’objets BLOB sont bonnes) alors
que les très petits fichiers inférieurs à 256 Ko ont de meilleures performances quand ils sont stockés
dans la base de données de contenu.
Nos constatations sont en phase avec le consensus général parmi les consultants selon lequel les
documents supérieurs à 512 Ko ou 1 Mo doivent être externalisés. C’est à partir de ce seuil que la
performance est améliorée pour les lectures et les écritures, dans le cas où les plates-formes de
stockage sous-jacentes ont des performances comparables. Toutefois, l’accès à un document inférieur
12
à 256 Ko est plus rapide avec le BLOB stocké dans la base de données de contenu SQL Server.
Entre 256 Ko et 512 Ko ou 1 Mo se trouve un point de bascule qui dépend fortement de la taille et des
fréquences d’accès. Par exemple, un fichier de 512 Ko qui est accédé fréquemment en lecture peut
bénéficier du cache SQL, et être plus rapide dans la base de données de contenu. Le même fichier,
archivé et accédé rarement pour modification, peut avoir de meilleures performances externalisé.
L’externalisation des BLOBs a un effet plus important sur les environnements où les fichiers sont souvent
modifiés.
La performance dépend aussi fortement de la solution spécifique EBS ou RBS que vous utilisez, et des
caractéristiques du magasin d'objets BLOB et de son stockage. Par exemple, un magasin d'objets BLOB
sur un SAN offrira bien sûr de meilleures performances qu’un magasin d'objets BLOB hébergé dans le
cloud public.
Le seuil à partir duquel la performance d’accès aux fichiers s’améliore dépend de divers facteurs, et
doit être testé avec votre solution de stockage EBS ou RBS ainsi qu’avec un contenu et des modalités
d’accès représentatifs de vos scénarios d’usage.
Performance des Bases de Données de contenu, du serveur SQL et de la ferme SharePoint
Il est inutile à notre avis de mettre trop d’énergie dans des discussions ou des tests sur le seuil
exact à partir duquel l’accès à un BLOB est amélioré dans votre environnement, à moins que votre
environnement ne consiste qu’en un utilisateur accédant à un document. Dans un environnement
SharePoint réel, plusieurs utilisateurs accèdent aux documents ainsi qu’aux listes, aux pages,
aux workflows, aux services, et aux applications. C’est pourquoi il est plus important de tester
l’environnement SharePoint dans des scénarios réels et complexes qui seront représentatifs d’une
utilisation au quotidien.
Lorsque de nombreux utilisateurs accèdent à SharePoint, l’impact des BLOBs sur SQL Server est
amplifié, et le stockage des objets BLOBs dans une base de données de contenu peut affecter
significativement la performance de l’ensemble de base de données de contenu, celle du serveur
exécutant SQL Server et par conséquent celles de la ferme SharePoint.
Comme mentionné précédemment, SQL Server est optimisé pour la performance avec des données structurées.
Quand vous stockez des données non structurées comme des BLOBs, SQL Server doit compenser
à chaque lecture et écriture. SQL Server n’est simplement pas optimisé pour être un serveur de fichiers.
La dégradation de la performance due aux BLOBs est aussi vraie hors de SQL Server et SharePoint. Un
client nous a indiqué avoir utilisé la fonctionnalité dans Oracle pour sortir les BLOBs partir de la base de
données dans une application métier, et avoir vu les performances monter en flèche.
Les effets sur la performance du stockage des BLOBs dans SQL Server sont perçus globalement dans
SharePoint, quand des utilisateurs accèdent aux documents, aux pages ou aux affichages de listes.
Si une base de données de contenu contient un grand nombre de BLOBs (par exemple une bibliothèque
de documents avec beaucoup de fichiers), et un niveau raisonnable d’activité nécessitant l’ accès aux
13
BLOBs, toutes les autres performances sont dégradées. Par exemple, la performance des affichages
des listes est ralentie. Lorsque certains utilisateurs téléchargent et stockent des BLOBs, l’utilisation
du processeur et de la mémoire augmente en flèche, et la performance est dégradée pour les autres
utilisateurs à travers toutes les bases de données de contenu stockées dans le même serveur SQL
Server. SQL Server devient le goulet d'étranglement et la performance de SharePoint souffre.
Nous avons observé que la simple existence de BLOBs peut dégrader visiblement la performance de
l’accès au contenu, même si l’accès que vous mesurez n'a rien à voir avec un document ou BLOB.
Cela est partiellement dû au fait que les services et les administrateurs SharePoint et SQL exécutent
en arrière-plan des opérations qui exploitent les BLOBS, comme l’indexation de base de données,
l’indexation de recherche, et les opérations de gestion telles que la sauvegarde de base de données –
qui implique l’accès aux BLOBs.
Quand vous externalisez les BLOBs d’une base de données, la performance de la base de données de
contenu et celle de SQL Server (utilisation processeur et mémoire) peuvent en être améliorées. Cela signifie
que la performance des affichages de listes, d’autres activités des utilisateurs ainsi que des opérations de
maintenance peut être nettement améliorée, même si ces activités ne sont pas liées aux BLOBs.
Par conséquent, bien qu'il soit intéressant de discuter de si un document de 512 Ko ou de 1 Mo doit
être externalisé ou non pour améliorer la performance d’accès à ce document, notre expérience est
qu’une telle discussion détourne de l’impact plus significatif des BLOBs (même les petits) dans les
environnements plus complexes.
Microsoft a signalé une augmentation de performance de 25 pourcent par l’externalisation des BLOBs,
à travers une série de charges de travail d’utilisateur qui reflètent un environnement de collaboration réel.
Les conclusions de Microsoft sont résumées ci-dessous.
BLOB SQL RBS Gain
Taille de base de données – 1To 2 292 Go 26 Go 98,9%
Taille de sauvegarde de base de données – 100Go 217 Go 7 Go 96,8%
Temps de sauvegarde de base de données – 217Go 2 490 s 38 s 98,5%
Temps de défragmentation de base de données – 100Go
120 s 4 s 96,7%
Temps moyen de réponse de SharePoint 28 ms 21 ms 25,0%
Téléchargement de fichier volumineux – 500Mo 55 s 29 s 47,6%
Source : La performance SQL Server RBS avec SharePoint Server 2010 et la solution de stockage StorSimple : http://www.microsoft.com/download/en/details.aspx?id=14726
14
Nous avons aussi réalisé des tests avancés sur l’impact des BLOBs dans les conditions réelles
d’utilisation, et nous en publierons les résultats détaillés de test à une date ultérieure. En ce moment, nos
observations qualitatives et les résultats quantitatifs de Microsoft permettent de conclure que le stockage
des BLOBs dans les bases de données de contenu SQL – même pour les petits BLOBs – peut dégrader
significativement la performance dans les environnements SharePoint réels.
Bien sûr, il y a de nombreux facteurs dans cette équation de performance, dont le volume total de
BLOBs et les types d’accès. Mais à cause de l’amélioration potentielle de performance de l’ensemble
de la base de données et du serveur, vous devez considérer la vue d’ensemble en prenant en compte
l’accès aux données au sein d’une base de données de contenu et d’une instance de SQL. Par exemple,
vous pouvez décider d’externaliser tous les BLOB supérieurs à 128 Ko ou 256 Ko afin d’améliorer
la performance à travers les scénarios les plus utilisés pour les collections de sites d’une base de
données de contenu, même si en agissant ainsi, vous pouvez dégrader la performance d’accès aux
très petits fichiers. Autrement dit, l’ouverture d’un petit fichier de 256 Ko sera peut-être plus lente, mais
tout le reste sera accéléré. C’est l’une des raisons pour lesquelles vous devez tester la performance de
l’externalisation des BLOBs dans votre environnement. Il n’existe aucune réponse facile, mais plutôt un
seuil qui est unique pour votre utilisation de SharePoint.
D’après notre expérience, le potentiel pour l’amélioration de la performance générale est sous-
documenté et sous-estimé. De trop nombreuses organisations déterminent le seuil de l’externalisation
des BLOBs uniquement d’après la documentation et les recommandations liées à la performance
de l’accès aux BLOBs. En d’autres termes, les organisations définissent un seuil qui peut être idéal
pour l’accès aux fichiers, même si ces fichiers ne sont pas accédés régulièrement, aux dépens de la
performance de l’ensemble de la base de données et du serveur.
Amélioration de la gestion du stockage et Réduction de l’espace occupé
Quand vous externalisez les BLOBs vers une plate-forme de stockage autre que SQL Server, vous
bénéficiez instantanément de l'ensemble de fonctionnalités de cette plate-forme. Par exemple, si vous
stockez les BLOBs dans un système de fichiers NTFS sur un serveur Windows, vous pouvez activer le
chiffrement NTFS. Le chiffrement des BLOBs peut être exigé dans votre environnement réglementaire.
Alternativement, vous pouvez stocker les BLOBs dans un volume SAN qui prend en charge l'instance
unique (la déduplication). Donc, si les utilisateurs stockent le même document dans plusieurs
emplacements, la plate-forme de stockage peut reconnaître la duplication et stocker uniquement une
instance du document.
Certaines plates-formes de stockage proposent la compression différentielle, où deux documents très
semblables sont stockés comme document principal et document de différence. Et beaucoup de plates-
formes de stockage peuvent exécuter elles-mêmes la compression de BLOBs.
Nous avons mentionné plus tôt dans ce livre blanc qu’un document peut être stocké plusieurs fois dans
un environnement typique de collaboration, particulièrement quand le contrôle de version est activé. De
telles fonctionnalités de stockage peuvent alors significativement réduire la capacité totale de stockage
requise pour prendre en charge votre contenu SharePoint, et donc réduire le coût de stockage.
15
Enfin, certaines plates-formes offrent des fonctionnalités de gestion de stockage précieuses. Par exemple,
beaucoup de sous-systèmes de stockage prennent en charge les captures instantanées (« snapshots»)
comme option de sauvegarde. Quelles que soient les fonctionnalités offertes par votre plate-forme de
stockage, ces fonctionnalités bénéficient à votre magasin d'objets BLOB.
Restructuration de contenu efficace
Dans le Service Pack 1 (SP1) de SharePoint 2010, Microsoft a introduit la prise en charge de la copie
superficielle (« shallow copy »). Cela signifie que vous pouvez déplacer le contenu (comme une collection
de sites) d’une base de données de contenu à l’autre dans une même application Web sans toucher aux
BLOBs du magasin d’objets BLOB. Les outils tiers vont plus loin en permettant de restructurer le contenu
entre applications Web ou fermes. Seul le contenu de la base de données de contenu (dont les pointeurs
vers le magasin de BLOBs) est déplacé.
Il y a certaines mises en garde et nuances pour cette fonctionnalité, mais c’est un ajout important aux
fonctionnalités de SharePoint, car cela permet de restructurer l’architecture logique et la conception d’une
application web SharePoint plus facilement et nettement plus vite.
Meilleure montée en charge
Stocker les BLOBs dans la base de données de contenu limite la capacité à monter en charge de
SharePoint si vous utilisez uniquement les outils et la configuration de SharePoint standard. Jusqu’en juillet
2011, la recommandation de Microsoft était de limiter les bases de contenu à 200 Go et les collections de
sites à 100 Go, à moins que ces dernières ne soient seules dans une base de données de contenu.
En juillet 2011, la recommandation de Microsoft pour la montée en charge des bases de données de
contenu a été considérablement modifiée (pour le mieux). Les bases de données de contenu sont prises
en charge jusqu’à 4 To dans les scénarios de collaboration, sans limite pour les archives de documents.
Microsoft a introduit aussi une limite supplémentaire : une base de données de contenu est supportée
jusqu’à 60 millions d’éléments, en comptant tous les éléments de liste et les documents de toutes les
collections de sites de la base de données de contenu. Le nombre total d'éléments dans une base de
données de contenu affecte le niveau de service des mises à niveau et mises à jour de SharePoint.
Pour une base de données de contenu dotée d’un trop grand nombre de lignes, les performances des
correctifs, mises à jour, Service Packs et mises à niveau peuvent être dégradées au point de ne pas se
terminer pendant la fenêtre de maintenance prévue, voire échouer complètement.
Toutefois, il y a un nombre de mises en garde liées à la performance et la gestion qui rendent difficile
d’approcher ou dépasser la limite d’1 To par base de contenu sans respecter les recommandations
suivantes :
Sous-systèmes de stockage de haute performance
Outils tiers pour compléter les outils de gestion standards
Externalisation des BLOBs
Utilisation de fonctionnalités de la couche de stockage pour respecter les niveaux de service pour la
restauration
Il est important de noter que l’externalisation des BLOBs peut permettre une meilleure montée en charge
(en combinaison avec une bonne architecture, une gouvernance globale,
16
et des outils de gestion efficaces). Par exemple, en externalisant les BLOBs vers un niveau de stockage
qui prend en charge les sauvegardes par capture instantanée, vous pouvez réduire considérablement le
temps de sauvegarde pour les bases de données de contenu volumineuses.
Cependant, l’externalisation des BLOBs ne modifie pas la limite de 4 To pour une base de données
de collaboration, ou toute autre limite de capacité ou montée en charge. Quand vous utilisez EBS ou
RBS pour externaliser les BLOBs, il vous faut tout de même respecter les limites de taille de la base de
données de contenu décrites plus tôt. Autrement dit, externaliser les BLOBs ne signifie pas pour autant
que vous pouvez mettre plus de données dans une base de données de contenu.
Il convient également de rappeler que l’externalisation des BLOBs en elle-même ne vous permet pas de
stocker un fichier unique supérieur à 2 Go. C’est une limite physique de la plate-forme SharePoint, et en
particulier de SQL Server. Des solutions tierces permettent de contourner cette limite, mais pas grâce à
EBS ou RBS.
Comme toute technologie, EBS et RBS ne sont pas des solutions miracles, et l’externalisation des BLOBs
n’est pas appropriée pour chaque scénario ou configuration. Nous avons déjà noté que certains scénarios
peuvent connaître une détérioration des performances qui doit être évaluée par rapport aux niveaux de
service et aux attentes des utilisateurs. Mais quels sont les autres inconvénients de l'externalisation des
BLOBs (les problèmes à prendre en compte)?
Complexité architecturale accrue
En externalisant les BLOBs, vous augmentez la complexité de votre architecture de stockage. Que cette
complexité architecturale se traduise ou non par une gestion plus complexe dépend en grande partie des
processus et des outils disponibles pour gérer SharePoint.
Sauvegarde, Restauration, Haute Disponibilité et Plan de Reprise des Activités
Les scénarios les plus critiques pour la plupart des organisations, sont en général liés à la sauvegarde,
à la restauration, à la haute disponibilité et à la reprise d’activité après sinistre. Lorsque les BLOBs
sont stockés dans SQL Server, la maintenance et la gestion de base de données sont simples : les
sauvegardes d’une base de données de contenu contiennent tout le contenu, y compris les BLOBs des
collections de sites stockées dans cette base de données de contenu.
Après l’externalisation des BLOBs, vous devez prendre en compte le magasin d’objets BLOB dans les
plans de sauvegarde, de restauration, de haute disponibilité et de reprise d’activité. Ici, l’histoire peut être
complexe, mais pas nécessairement. La clé est de bien comprendre votre implémentation qui inclut votre
configuration d'EBS ou de RBS, vos outils et vos procédures. Vous devez avoir testé pour vous assurer
que vous pouvez satisfaire vos SLAs pour la sauvegarde, la restauration, la haute disponibilité et la reprise
d’activité.
Considérations
17
Sauvegarde et Restauration Standard
Prenons RBS et le fournisseur FILESTREAM comme exemple. Si vous externalisez les BLOBs avec RBS
et FILESTREAM, vous êtes en train d’utiliser une API SQL et un fournisseur pour déterminer ce qui est
redirigé vers le magasin d’objets BLOB et ce qui ne l’est pas.
Si vous utilisez les APIs de sauvegarde de SharePoint (sauvegarde via l'Administration centrale ou
Windows PowerShell), SharePoint demande le contenu de SQL, et SQL fournit le contenu, récupérant
les métadonnées provenant de la table AllUserData et les BLOBs provenant du magasin d’objets BLOB.
Votre sauvegarde inclura les fichiers du magasin d’objets BLOB. De même, si vous utilisez les APIs de
sauvegarde de SQL (Sauvegarde via SQL Server Management Studio), votre sauvegarde comprendra
les BLOBs du magasin d’objets BLOB. Microsoft prend en charge explicitement la sauvegarde et la
restauration de base de données de ferme à l’aide du fournisseur FILESTREAM.
Cependant, d’autres fournisseurs RBS, l'externalisation par EBS, et d’autres outils de sauvegarde et de
restauration se comportent différemment. Par conséquent, vous devez examiner plusieurs facteurs par
rapport aux niveaux de service(SLAs) que vous avez définis pour SharePoint.
Point de reprise et perte de données acceptable
Les niveaux de service (SLAs) de votre restauration doivent indiquer l’objectif de point de reprise (ou
RPO, Recovery Point Objective), qui se rapporte directement à la fréquence des sauvegardes. Si les
sauvegardes sont prises toutes les heures, le SLA pour l’objectif de point de reprise est également d’une
heure : la quantité maximale données perdues est égale au temps entre deux sauvegardes.
Lors de l’externalisation des BLOBs, vous devez vous assurer que la sauvegarde de votre base de
données de contenu SQL et la sauvegarde de votre magasin d’objets BLOB sont compatibles avec les
SLAs que vous avez définis pour SharePoint.
L’idéal serait que les sauvegardes de base de données de contenu et de magasin d’objets BLOB
soient synchronisées et maintiennent la cohérence de données. Il y a des solutions tierces logicielles et
matérielles qui atteignent ce but.
Certaines solutions logicielles tierces sauvegardent chaque document comme unité complète qui contient
les métadonnées et le BLOB. Une telle sauvegarde s’assure que le document peut être récupéré tel qu’il
était au moment de sa sauvegarde.
Certaines plates-formes de stockage supportent les sauvegardes de captures instantanées, qui peuvent
sauvegarder des téraoctets de données en quelques secondes seulement. De telles solutions peuvent
être coûteuses, mais elles sont souvent critiques dans les scénarios de contenu volumineux. Elles ne sont
cependant pas toujours nécessaires, tant que la fenêtre de risque de perte de données est compatible
avec vos SLAs SharePoint.
Il est également possible de gérer séparément les sauvegardes d'une base de données de contenu et de
son magasin d’objets BLOB associé. Il y a beaucoup d’exagération à propos de la complexité de cette
opération. Ce n'est pas compliqué du tout, tant que vous comprenez la séquence d’opérations à réaliser
ainsi que le risque d’une fenêtre supplémentaire de perte de données.
18
Le processus de sauvegarde d'une base de données de contenu et de son magasin d’objets BLOB
associé est le suivant :
1. Sauvegarder la base de données de contenu
2. Sauvegarder le magasin d’objets BLOB
Le temps entre le début de l'étape 1 et la fin de l'étape 2 représente une période de perte de données
partielles lors d’une opération de restauration. Considérez que vous sauvegardez la base de données
de contenu. Après la fin de la sauvegarde, mais avant de commencer à sauvegarder le magasin d’objets
BLOB, un utilisateur ajoute un document ou une version de document à SharePoint. Le BLOB du
document entre dans le magasin d’objets BLOB, et est sauvegardé. Les métadonnées et le pointeur au
BLOB sont placés dans la base de données de contenu, mais après la sauvegarde.
Si une restauration totale est nécessaire, vous devez exécuter les étapes suivantes :
1. Restaurer le magasin d’objets BLOB
2. Restaurer la base de données de contenu
Le magasin d’objets BLOB contient le document nouvellement ajouté, mais pas la base de données de
contenu, donc le document ne sera pas visible pour SharePoint. Un processus appelé nettoyage de
la mémoire s'exécute périodiquement pour purger les BLOBs orphelins du magasin d’objets BLOB. Le
document qui a été ajouté lors de l’intervalle entre la sauvegarde de la base de contenu et la sauvegarde
des BLOBs a été effectivement perdu.
Il est intéressant de noter que vous n'avez pas besoin de vous inquiéter autant des suppressions.
Considérez qu'une base de données de contenu est sauvegardée à 1 heure du matin, et qu’un utilisateur
supprime de manière définitive un document de SharePoint (y compris les Corbeilles) à 1 heure 10 du
matin.
Lorsqu’un document est supprimé de SharePoint, l'information est enlevée de la base de données de
contenu, mais le BLOB lui-même n'est supprimé que par le processus de nettoyage de la mémoire. Donc
le BLOB reste dans le magasin d’objets BLOB.
Le magasin d’objets BLOB est alors sauvegardé à 1 heure 15 du matin.
Dans un scénario de restauration, le magasin d’objets BLOB est récupéré d'abord avec le BLOB orphelin
du document supprimé. La base de données de contenu est récupérée dans son état avant que le
document ait été supprimé. Le document est effectivement totalement restauré tel qu'il existait à 1 heure
du matin— le moment de la sauvegarde de bases de données de contenu.
Par conséquent, la recommandation pour la sauvegarde est de tester la restauration de vos sauvegardes
pour vous assurer que les BLOBs sont protégés à un niveau qui répond à vos SLAs pour l’objectif de point
de reprise (RPO) et la perte de données. Vous devez valider que votre sauvegarde et votre restauration
fonctionnent comme prévu selon les configurations de votre base de données et de votre magasin d’objets
BLOB, les APIs que vous employez (EBS ou RBS), et les outils spécifiques et les processus que vous avez
en place.
19
Fenêtre de sauvegarde et objectif de temps de reprise
Une autre considération significative pour les SLAs de sauvegarde et de restauration est le temps
nécessaire pour sauvegarder ou restaurer le contenu. Si vous avez un grand magasin d’objets BLOB, la
sauvegarde peut ne pas avoir le temps de s’achever au cours de l’intervalle de maintenance de votre SLA.
Et si vous devez restaurer le contenu, cela pourrait prendre trop de temps de transférer la sauvegarde de
la bande ou d’un autre média de sauvegarde à votre serveur SQL avant même de commencer à restaurer
le contenu.
Les outils de gestion standard de SharePoint exigent, pour restaurer le contenu, de commencer par copier
ou restaurer la base de données sauvegardée depuis vos sauvegardes sur bande ou archives de disque
vers SQL Server, puis de procéder à l'opération de restauration SharePoint.
Jusqu'à récemment, Microsoft ne supportait les bases de données de contenu que jusqu’à 200 Go. Une
des raisons de cette limite était la de pouvoir proposer des SLAs raisonnables d'objectif de temps de
reprise (RTO). Si la taille d’une base de données de contenu est de plusieurs centaines de gigaoctets,
sa copie ou sa restauration vers SQL Server peut prendre un temps considérable avant que le contenu
puisse être récupéré effectivement.
Des solutions tierces matérielles et logicielles peuvent réduire l'objectif de temps de reprise (RTO) de
manière significative par différents moyens, y compris les captures instantanées et la capacité de monter
directement les sauvegardes à distance.
Haute disponibilité et Plan de Reprise d’Activité (PRA)
Le stockage externalisé de BLOBs doit également être pris en compte pour les scénarios de haute
disponibilité et les plans de reprise d’activité. Pour fournir une haute disponibilité au niveau des bases de
données de SharePoint, vous pouvez installer SQL Server sur un cluster, ce qui assure l'accès aux bases
de données en cas d’indisponibilité du serveur principal du cluster. Vous pouvez utiliser l’envoi de journaux
(log shipping) pour créer un serveur de secours à chaud de vos bases de données SQL Server en vue
d'une reprise après sinistre.
SQL Server 2008 R2 propose également la mise en miroir SQL (mirroring), qui offre un accès redondant
aux fichiers de bases de données eux-mêmes en cas de corruption ou de défaillance de la plate-forme de
stockage. Cependant, la mise en miroir de SQL n'est pas prise en charge pour les bases de données de
contenu qui utilisent RBS pour externaliser les BLOBs.
Cependant, chacune de ces approches de haute disponibilité et de reprise d’activité ne protège que les
bases de données de contenu. Le magasin d’objets BLOB doit également être hautement disponible et
récupérable. La configuration qui active le « lien » entre les métadonnées dans la base de données de
contenu et un BLOB spécifique dans le magasin d’objets BLOB doit également basculer correctement.
Il n'y a ni meilleure pratique unique ni « recette » pour configurer la haute disponibilité et la reprise
20
d’activité avec les BLOBs externalisés. Vous devez donc concevoir une solution basée sur vos besoins
métier et techniques, en fonction de vos plates-formes matérielles et logicielles, de vos équipes, de leurs
compétences et de vos procédures.
Dans un prochain article, nous examinerons le matériel, les logiciels et les procédures pour supporter la
haute disponibilité, la reprise après sinistre, et la sauvegarde et la restauration.
Microsoft propose gratuitement le fournisseur FILESTREAM pour RBS, et pourtant la plupart des
entreprises se tournent vers une solution tierce pour prendre en charge l’externalisation des BLOBs et
supporter les SLAs de sauvegarde et restauration des environnements de grande taille. Ces solutions
tierces comblent les lacunes entre les besoins métier et les capacités standard de SharePoint.
Fonctionnalités d’externalisation des BLOBs
Les tables suivantes résument certaines fonctionnalités offertes par les éditeurs de logiciels qui étendent
les fonctionnalités du fournisseur FILESTREAM. Dans le cadre de cette table, des solutions tierces
exploitant EBS et RBS sont incluses.
Prise en charge pour les versions et le stockage SharePoint
Options pour externaliser les BLOBs
FONCTIONNALITÉ FILESTREAM SOLUTION TIERCE
SharePoint 2010 (Server et Foundation)
SharePoint 2007 (MOSS 2007 et WSS v3)
Toutes les versions de SQL (2000, 2005, 2008, 2008 R2)
Toutes les éditions de SQL (Express/Standard/Enterprise)
Externaliser les BLOBs vers DAS, NAS/SAN iSCSI
Externaliser les BLOBs vers un partage de fichiers oustockage WORM
Externaliser vers le cloud (Azure, Amazon, etc.)
Compression et chiffrement natifs
Externaliser vers plusieurs fournisseurs de stockage au seind’une même base de données de contenu
21
Sauvegarde, récupération, et récupération d’urgence
Prise en charge de cycle de vie du contenu
FONCTIONNALITÉ FILESTREAM SOLUTION TIERCE
La sauvegarde standard de SharePoint capture les BLOBset les métadonnées
Sauvegardes synchrones, séparées du magasin d’objetsBLOB et de SharePoint
Sauvegarde de la base de données de contenuindépendante du magasin d’objets BLOB
Restauration au niveau des éléments
Restauration de toute la plate-forme
Restauration sans avoir à restaurer toute la base de données
FONCTIONNALITÉ FILESTREAM SOLUTION TIERCE
Restructuration du contenu (copie superficielle) au sein d’uneapplication Web
Restructuration du contenu (copie superficielle) d’une application Web à l’autre
Réplication de contenu
Se connecter aux partages de fichiers et les gérer viaSharePoint
Se connecter aux partages de médias et les gérer parSharePoint
Prise en charge de règles métier (type de contenu,métadonnées, date d’accès)
Externaliser vers un système de stockage hiérarchisé
22
Examen des solutions tierces
Lorsque vous examinez les solutions tierces, évaluez-les pour les caractéristiques suivantes :
Performance
Prise en charge de la plate-forme de magasin d’objets BLOB de votre choix
Système de fichier, SAN, NAS
Dossier partagé
Stockage dans le cloud
Intégration avec votre plate-forme de stockage
Règles qui peuvent être appliqués pour déterminer si les BLOBs sont externalisés
Taille de fichier
Dernière date d’accès
Type de contenu
Métadonnées
Autres règles métier
Facilité de gestion
Facilité d’installation et de configuration
Tâches de maintenance
Rapports et supervision
Prise en charge des niveaux de service (SLAs) pour la sauvegarde et la restauration de contenu avec
fidélité complète des métadonnées et des BLOBs
Prise en charge des niveaux de service pour la haute disponibilité
Prise en charge des niveaux de service pour la reprise sur sinistre
Gestion de la rétention à long terme, de l’archivage et du stockage hiérarchisé
Coût
Conclusion
L’infrastructure de stockage de SharePoint 2010 doit offrir un référentiel disponible, administrable
et montant en charge en phase avec les niveaux de service et les attentes des utilisateurs. Plus les
organisations utilisent SharePoint pour la gestion de contenu et la collaboration, plus les documents
prolifèrent (stockés dans les BLOBs). Conserver les BLOBs dans une base de données de contenu
augmente la charge de stockage de niveau 1, le plus cher. En externalisant les BLOBs, une organisation
peut réduire le coût, optimiser la performance, simplifier la gestion, réduire l’espace de stockage
nécessaire, restructurer le contenu, et améliorer la montée en charge. Mais, comme toutes les
technologies, l’externalisation des BLOBs doit être évaluée en fonction de vos propres scénarios. Vous
devez donc porter beaucoup d’attention à la conception, l’implémentation, et la maintenance d’une
architecture de stockage qui inclut l’externalisation des BLOBs.
Ressources
Veuillez consulter les ressources suivantes, qui donnent des conseils et un contexte complémentaires aux
arguments, recommandations et conclusions présentés dans ce livre blanc.
23
Gestion de la capacité SharePoint Server 2010 : limitations et frontières logicielles :
http://technet.microsoft.com/fr-fr/library/cc262787.aspx#Column
SharePoint 2010 : Améliorer les performances de SharePoint 2010 avec RBS :
http://technet.microsoft.com/fr-fr/magazine/ff847521.aspx
Installer et configurer RBS (SharePoint Foundation 2010) :
http://technet.microsoft.com/fr-fr/library/ee663474.aspx
Blog de l’équipe SharePoint : Modifications du stockage des données dans SP1 :
http://sharepoint.microsoft.com/blog/Pages/BlogPost.aspx?pID=988
MSDN : Stockage externe des objets BLOB (Binary Large Objects) dans SharePoint Foundation :
http://msdn.microsoft.com/fr-fr/library/bb802976.aspx
Livre blanc : Performance de RBS SQL Server avec SharePoint Server 2010 : http://www.microsoft.com/download/en/details.aspx?id=14726
Performance de RBS SQL Server avec SharePoint 2010 et solution de stockage StorSimple :
http://www.microsoft.com/download/en/details.aspx?id=14726
Estimer les besoins en performances et capacité pour la recherche SharePoint Server 2010 :
http://technet.microsoft.com/fr-fr/library/gg750251.aspx
Gérer le cache Office Web Apps :
http://technet.microsoft.com/fr-fr/library/ee837422.aspx
Remerciements
Les auteurs souhaitent remercier George Wang, Mary Leigh Mackie et Christopher Musico pour leurs
contributions incroyables à ce livre blanc.
2011 AvePoint, Inc. Tous droits réservés. Aucune partie de cette publication ne peut être reproduite,
stockée dans un système de récupération, ou transmise, à quelque fin ou par quelque moyen que ce
soit électronique, mécanique, photocopie, enregistrement ou autre, sans le consentement écrit préalable
d’AvePoint, 3 Second Street, Jersey City, NJ 07311, USA.
Marques
AvePoint DocAve®, le logo AvePoint, et AvePoint, Inc. sont les marques déposées d’AvePoint, Inc.
Microsoft, MS-DOS, Internet Explorer, Microsoft SharePoint Server 2010, Microsoft Office SharePoint
Server 2007, SharePoint Portal Server 2003, Windows SharePoint Services, Windows SQL server et
Windows sont soit les marques déposées soit les marques de Microsoft Corporation. Adobe Acrobat et
Acrobat Reader sont les marques d’Adobe Systems, Inc. Toutes les autres marques sont déposées par les
sociétés qui en sont propriétaires.
24
Modifications
Ce document est fourni uniquement à titre informatif est sujet à modification sans préavis. Malgré toute
l’attention apportée à la préparation de ce document pour s’assurer sa précision, AvePoint n’assume
aucune responsabilité résultant des erreurs ou des omissions dans ce document ou de l’utilisation des
informations qu’il contient. AvePoint se réserve le droit de modification dans la conception de ses produits
sans réserve et sans notification pour ses utilisateurs.
