Changements dans le stockage des données SharePoint 2010
Article d’origine publié le samedi 9 juillet 2011
Nous annonçons aujourd’hui deux changements connexes dans la description du stockage des données SharePoint. D’abord, grâce aux améliorations de performances et de fiabilité du SP1 et en définissant des conditions spécifiques pour le stockage des données volumineuses dans SharePoint, Microsoft est en mesure d’augmenter les limites prises en charge pour le stockage des données dans SharePoint.
Par ailleurs, nous annonçons que le fournisseur SQL Server FILESTREAM RBS est désormais pris en charge avec SharePoint et que les disques NAS connectés via iSCSI, moins onéreux, sont donc utilisables. Ce billet dévoile les nouvelles limites prises en charge de stockage des données, donne des conseils pour évoluer vers ces limites et définit RBS, y compris le nouveau fournisseur FILESTREAM RBS.
Limite de taille des bases de données de contenu SharePoint
Avec la sortie de SharePoint 2010 SP1 et quelques nouvelles directives, nous changeons les limites de taille de données prises en charge pour les bases de données de contenu SharePoint. Avant le SP1, la limite d’une base de données de contenu était de 200 Go pour la collaboration et de 1 To pour l’archivage de documents. La taille d’une base de données de contenu inclut les métadonnées et les BLOB, indépendamment de l’emplacement des BLOB ; RBS ne contourne pas et n’augmente pas ces limites.
Concernant la taille des bases de données de contenu prise en charge, de nouvelles directives s’adressent aux administrateurs SharePoint pour gérer l’augmentation de la taille des données. Si ces directives sont suivies, SharePoint peut prendre en charge jusqu’à 4 To de données dans tous les scénarios d’utilisation et n’impose aucune limite de taille pour l’archivage des documents. Vous trouverez les détails dans le document TechNet « Gestion de capacité SharePoint Server 2010 : limitations et frontières logicielles ». Les principaux changements sont :
- Pour une base de données de contenu SharePoint jusqu’à 200 Go, il n’y a aucune exigence spéciale et cette limite est incluse pour la cohérence.
- Pour une une base de données de contenu SharePoint jusqu’à 4 To, vous devez prendre en compte les deux conditions supplémentaires suivantes :
- Performances du sous-système de disques de 0,25 E/S par seconde par Go requise, 2 E/S par seconde par Go recommandé pour des performances optimales.
- Des plans pour une haute disponibilité, la récupération d’urgence, la capacité future et les tests de performance sont requis.
- Vous devez aussi examiner les considérations supplémentaires listées dans l’article TechNet sur les limitations et frontières logicielles.
- Pour une une base de données de contenu SharePoint de plus de 4 To, spécifiquement pour un scénario d’archivage de documents, vous devez aussi prendre en compte les points suivants :
- Les sites SharePoint doivent être basés sur des modèles de site Centre de documents ou Centre d’enregistrements ; il doit s’agir d’un scénario d’archivage où, chaque mois, moins de 5 % du contenu du site est lu activement et moins de 1 % du contenu écrit activement.
- N’utilisez pas des alertes, des flux de travail, des réparations de liens, ni la sécurité au niveau de l’élément sur aucun objet SharePoint dans la base de données de contenu. Remarque : les bases de données de contenu d’archivage de documents peuvent être destinataires de documents résultant d’un flux de travail de routage de contenu.
- Autres changements de limites spécifiques apportés en même temps :
- Nouvelle limite de 60 millions d’éléments dans une base de données de contenu SharePoint
- La limite spécifique de 5 To par instance SQL Server a été supprimée. Au lieu de cela, il est recommandé de planifier le stockage de base de données avec un spécialiste SQL Server.
Consultez l’article TechNet complet Gestion de la capacité SharePoint Server 2010 : limitations et frontières logicielles. Nous avons également publié un guide sur l’évolutivité de SharePoint 2010 ici : https://go.microsoft.com/fwlink/?LinkId=223599. Dans un proche avenir, nous allons publier un rapport de tests à grande échelle prenant en charge ces nouvelles limites de taille.
Valeur du magasin Blob distant avec SharePoint
RBS (Remote Blob Store) est un ensemble d’API normalisées permettant le stockage et la récupération des données BLOB (Binary Large Object) en dehors de votre base de données SQL principale, lorsqu’un magasin BLOB est souhaitable. RBS utilise un modèle de fournisseur pour connecter un magasin BLOB dédié qui implémente les API RBS. RBS a été introduit dans SharePoint 2010 ; des fournisseurs peuvent être installés dans SharePoint et utilisés pour stocker les BLOB. Les documents des bibliothèques de documents SharePoint sont des BLOB et, avec RBS, peuvent être stockés à distance dans la base de données SQL Server. Généralement, cela signifie que les BLOB sont stockés sur le même ordinateur que SQL Server, mais ils peuvent aussi résider sur un ordinateur SQL Server connecté au réseau.
Les deux diagrammes ci-dessus illustrent des architectures courantes SharePoint utilisant RBS. Les deux montrent le fournisseur client RBS qui est installé sur le serveur Web frontal SharePoint. Le diagramme de gauche illustre l’implémentation RBS générique d’une partie tierce pour accéder à son stockage. Le diagramme de droite montre le fournisseur SQL Server FILESTREAM RBS qui stocke les BLOB dans le système de fichiers Windows.
Le stockage des BLOB en dehors de la base de données SQL Server peut offrir certains avantages comme :
· RBS permet à SharePoint Foundation 2010 s’exécutant sur SQL Express de stocker davantage de données que la limite SQL Express de 4 Go. Dans SQL Express 2008 R2, cette limite a été élevée à 10 Go.
· Les performances de certaines opérations peuvent être optimisées avec des tailles de BLOB de plus de 1 Mo en moyenne. Ce résultat est tiré de tests avec le fournisseur SQL RBS. Référence : https://msdn.microsoft.com/fr-fr/library/cc949109(SQL.100).aspx
· Des optimisations du stockage sont possibles en espace disque potentiel et en économie sur les coûts de disque grâce aux sauvegardes différentielles ou au stockage en niveaux.
· Nous avons réalisé des tests sur le fournisseur SQL RBS FILESTREAM qui permet le stockage connecté via iSCSI pour l’utilisation de RBS. iSCSI permet l’utilisation de stockage NAS moins onéreux.
· Des éditeurs de logiciels indépendants peuvent développer d’autres optimisations en utilisant les API RBS publiques prises en charge et les API SharePoint.
Lors de l’implémentation de RBS, les points suivants sont à considérer avec attention :
· La stratégie de sauvegarde doit être soigneusement étudiée. Les métadonnées de document et les BLOB de document doivent être sauvegardés exactement au même moment. Toute solution de sauvegarde tierce doit donc être capable de restaurer la base de données SQL utilisée par SharePoint et les BLOB utilisés par SharePoint sous forme d’ensemble sans divergences dans lesquelles des BLOB référencés dans la base de données ne seraient pas disponibles dans la même sauvegarde.
· RBS est recommandé pour les scénarios d’archivage de documents où des documents sont écrits et ne sont pas mis à jour. Les BLOB dans RBS ne sont jamais mis à jour une fois écrits, mais un nouveau BLOB est créé pour toute mise à jour. Les BLOB sont immuables, les anciens BLOB sont récupérés par le garbage collector ultérieurement. Pour en savoir plus sur le nettoyage de la mémoire RBS, lisez cet article : https://technet.microsoft.com/fr-fr/library/ff628583.aspx
· Des fournisseurs RBS sont requis pour retourner le premier octet de données d’une requête en 20 ms. Cela s’applique à toutes les requêtes entre SharePoint et la couche de stockage du fournisseur RBS.
· La base de données SharePoint n’est pas conçue pour être lue ou écrite, excepté par SharePoint. Les fournisseurs RBS n’ont pas un accès séparé aux données. Cela inclut l’accès direct aux BLOB. Référence : https://support.microsoft.com/kb/841057/fr-fr
· Les performances peuvent diminuer pour des tailles de BLOB inférieures lors de l’utilisation de RBS. L’article référencé ci-dessus « Stockage FILESTREAM dans SQL Server 2008 » le montre également.
· De nombreux fournisseurs RBS sont disponibles et les clients doivent évaluer leur pertinence dans le cadre de leur implémentation.
Documentation Microsoft supplémentaire sur RBS dans SharePoint
Liens vers la documentation TechNet sur RBS :
· Planifier le stockage BLOB distant (RBS) (SharePoint Server 2010) [https://technet.microsoft.com/fr-fr/library/ff628583.aspx]
· Vue d’ensemble du stockage BLOB distant (SharePoint Server 2010) [https://technet.microsoft.com/fr-fr/library/ee748649.aspx]
· Gérer le stockage BLOB distant (SharePoint Server 2010) [https://technet.microsoft.com/fr-fr/library/ff943565.aspx]
Questions et réponses
· Q : Pourquoi n’avez-vous pas fourni ces limites de données rehaussées au lancement de SharePoint 2010 ?
· R : Nous en avons appris davantage sur la façon dont les clients implémentent des solutions d’archivage de documents sur SharePoint au cours des 12 derniers mois. Maintenant, en fournissant des directives spécifiques à propos de l’évolution de la taille des données et en ciblant la soutenabilité de celles-ci, nous permettons une limite de taille élevée pour SharePoint et éliminons toute limite de taille pour l’archivage des documents.
· Q : Quelle est la nouvelle limite de taille pour les archives de documents dans SharePoint ?
· R : Il n’y a aucune limite de taille, bien que les facteurs des nouvelles directives doivent être respectés pour bâtir des systèmes à grande échelle pris en charge. Si les facteurs supplémentaires ne sont pas correctement traités, la limite de soutenabilité inférieure s’applique.
· Q : Comment faire si je nécessite réellement plus de 4 To sur une batterie de serveurs SharePoint et qu’il ne s’agit pas d’archivage de documents ?
· R : Il vous faut utiliser une topologie d’échelle. Cela implique la présence de plusieurs bases de données de contenu sur une seule batterie de serveurs et de répartir les sites sur celles-ci. Chaque base de données de contenu peut occuper jusqu’à 4 To en respectant les directives.
· Q : Que faire si j’ai à tort supposé que la limite de 200 Go pouvait être évitée en déplaçant les BLOB vers un fournisseur de stockage BLOB distant, réduisant ainsi la quantité de données stockées par SQL Server pour SharePoint ?
· R : Nous vous recommandons de mettre à niveau vers SharePoint 2010 SP1 et de respecter les nouvelles directives pour la taille totale que vous avez. Consultez la société qui vous a vendu le fournisseur RBS pour s’assurer qu’il a été testé avec SharePoint 2010 SP1. Si vous avez un déploiement qui dépasse les nouvelles et anciennes limites, nous vous recommandons de contacter le support Microsoft et de demander un examen de soutenabilité. Cet examen est payant et l’ingénieur support sera capable de diagnostiquer si votre implémentation actuelle peut être prise en charge ou si des changements pour réduire la quantité de données par base de données de contenu sont recommandés.
· Q : Puisque NAS est pris en charge, le fournisseur SQL Server RBS FILESTREAM permet-il l’utilisation d’un partage réseau pour le stockage des BLOB ?
· R : Non, NAS doit être connecté en utilisant iSCSI et apparaît comme un lecteur local sur l’ordinateur SQL Server.
· Q : La limite de taille des bases de données de contenu ou la limite de temps jusqu’au premier octet (TTFB) de 20 mS seront-t-elle imposées dans le logiciel ?
· R : Non. Ce sont des limites de prise en charge que nous recommandons pour conserver des performances optimales et obtenir un support optimal de la part de Microsoft. Il ne s’agit pas de limites strictes mesurées par le logiciel SharePoint.
· Q : Où l’ancienne limite de 200 Go est-elle documentée sur TechNet ?
· R : Elle a été indiquée sur la page TechNet « Gestion de la capacité SharePoint : limitations et frontières logicielles ». Bien que RBS et les BLOB n’aient pas été spécifiquement cités, la limite de 200 Go était clairement indiquée pour une base de données de contenu SharePoint incluant des métadonnées et des BLOB. Cet article a été mis à jour avec les nouvelles limites et pour lister RBS afin d’être plus explicite et d’éviter toute mauvaise interprétation à l’avenir.
· Q : Un archivage important de documents peut-il englober plusieurs collections de sites SharePoint ?
· R : Oui. Cependant, nos directives sont que si vous avez une collection de sites qui dépasse 100 Go, elle doit être la seule collection de sites dans une base de données de contenu.
· Q : Un archivage important de documents peut-il englober plusieurs bibliothèques de documents ?
· R : Oui. Vous pouvez avoir plusieurs bibliothèques de documents avec différents jeux d’autorisations.
· Q : SharePoint 2010 SP1 est-il requis pour tirer profit de ces nouvelles limites des bases de données de contenu ?
· R : Non. Les limites s’appliquent à SharePoint 2010, que le SP1 soit installé ou non. Cependant, étant donné les améliorations apportées par SharePoint 2010 SP1, il est vivement conseillé de l’installer.
Ce billet de blog a été traduit de l’anglais. L’article d’origine est disponible ici : Data Storage Changes for SharePoint 2010