Reconcevoir la topologie de recherche d’entreprise pour plus de contenu et d’utilisateurs dans SharePoint
S’APPLIQUE À :
2013 2016 2019 Édition d’abonnement 
SharePoint dans Microsoft 365
Au fil du temps, la plupart des environnements de recherche augmentent, à la fois en quantité de contenu et en nombre d’utilisateurs. À un moment donné, l’environnement de recherche dépasse la capacité et les performances de votre architecture de recherche. La solution consiste à mettre à l’échelle la topologie de votre architecture de recherche :
Reconcevez votre topologie (voir le présent article).
Implémentez la topologie redéfinie (Gérer la topologie de recherche dans SharePoint Server).
Connaissez-vous les composants du système de recherche dans SharePoint Server et la façon dont ils interagissent ? Lisez la rubrique Vue d'ensemble de l'architecture de recherche dans SharePoint Server et le document Architectures de recherche pour SharePoint Server 2016 (ou Architectures de recherche pour SharePoint Server 2013) avant de continuer pour apprendre à connaître l'architecture de recherche, les composants de recherche, les bases de données de recherche et la topologie de recherche.
Dans cet article, nous allons vous montrer pas à pas comment reconcevoir votre topologie de recherche.
Étape 2 : Quelle architecture de recherche de taille dois-je mettre à l’échelle ?
Étape 3 : De quelle configuration matérielle requise dois-je tenir compte ?
Une fois que vous aurez suivi ces étapes, vous connaîtrez :
le nombre de chaque type de composant de recherche et de base de données de recherche dont votre topologie a besoin ;
les serveurs d’applications et les serveurs de base de données sur lesquels déployer chaque composant de recherche ;
les ressources matérielles dont chaque serveur d’applications et chaque serveur de base de données a besoin.
Étape 1 : Quel est le volume de contenu dont je dispose ?
Le volume de contenu dont vous disposez dans votre index de recherche a une incidence sur les ressources dont vous avez besoin pour héberger la batterie. Vérifiez le nombre d’éléments pouvant faire l’objet d’une recherche dans votre environnement de recherche existant. Vous trouverez ce numéro dans la page Administration de la recherche du site web Administration centrale de SharePoint. Pour ouvrir la page d’administration de la recherche, cliquez sur Gérer les applications de service dans l’Administration centrale, puis cliquez sur le nom de l’application de service de recherche.
Estimez le nombre d’éléments pouvant faire l’objet d’une recherche au cours des 12 prochains mois et concevez la topologie de recherche pour ce montant. Par exemple, si vous avez 8 000 000 éléments indexés et que vous prévoyez que le volume de ce contenu augmentera de 50 % au cours des 12 prochains mois. Vous devez concevoir pour 12 000 000 éléments pouvant faire l’objet d’une recherche.
Étape 2 : Quelle architecture de recherche de taille dois-je mettre à l’échelle ?
Il n'est pas toujours facile d'évaluer la taille que doit avoir votre architecture de recherche. Celle-ci dépend du volume de votre contenu, du taux d'analyse, du débit de requête et du niveau de haute disponibilité requis. Microsoft a testé des exemples d’architectures de recherche que nous vous conseillons d’utiliser comme base pour votre propre batterie de serveurs. Comparez votre architecture de recherche actuelle avec les exemples d’architectures de recherche et déterminez l’exemple qui représente le mieux votre architecture de recherche actuelle. Réfléchissez ensuite à l’exemple d’architecture de recherche vers lequel effectuer la mise à l’échelle. L'exemple d'architecture de recherche à utiliser dépend du volume du contenu pouvant faire l'objet d'une recherche :
| Volume de contenu (SharePoint 2016) | Exemple d'architecture de recherche | Volume de contenu (SharePoint 2013) |
|---|---|---|
| 0-20 millions d’articles | Batterie de recherche de petite taille | 0 à 10 millions d'éléments |
| 0-80 millions d’articles | Batterie de recherche de taille moyenne | 0-40 millions d’articles |
| 0-200 millions d’articles | Batterie de recherche de grande taille | 0-100 millions d’articles |
| 0-500 millions d’articles | Batterie de serveurs de recherche très volumineuse | Non pris en charge |
Bien que ces exemples d’architectures de recherche utilisent des machines virtuelles, vous pouvez utiliser des serveurs physiques et des machines virtuelles en fonction de la stratégie de la solution SharePoint Server globale de votre architecture de recherche.
Batterie de recherche de petite taille
Nous avons estimé que cette architecture de recherche peut analyser 50 documents par seconde et servir de l’ordre de 10 requêtes par seconde. Si vous avez jusqu’à 20 millions d’éléments dans une batterie de serveurs SharePoint Server 2016, la petite batterie de serveurs de recherche sera probablement la batterie de serveurs qui vous convient le mieux. Avec un taux d’analyse de 50 documents par seconde, la recherche prend 110 heures pour analyser 20 millions d’éléments dans la première analyse complète.
Batterie de recherche de taille moyenne
Nous avons estimé que cette architecture de recherche peut analyser 100 documents par seconde et servir de l’ordre de 10 requêtes par seconde. Si vous avez entre 20 et 80 millions d’éléments dans une batterie de serveurs SharePoint Server 2016, la batterie de serveurs de recherche moyenne sera probablement la batterie de serveurs qui vous convient le mieux. Avec un taux d’analyse de 200 documents par seconde, la recherche prend 280 heures pour analyser 80 millions d’éléments dans la première analyse complète.
Batterie de recherche de grande taille
Nous avons estimé que cette architecture de recherche peut analyser 200 documents par seconde et servir de l’ordre de 10 requêtes par seconde. Si vous avez entre 80 et 200 millions d’éléments dans une batterie de serveurs SharePoint Server 2016, la batterie de serveurs de recherche volumineuse sera probablement la batterie de serveurs qui vous convient le mieux. Avec un taux d’analyse de 200 documents par seconde, la recherche prend 280 heures pour analyser 200 millions d’éléments dans la première analyse complète.
Batterie de serveurs de recherche extra-volumineuse
Microsoft a testé cette architecture de recherche et a mesuré qu’elle peut analyser 300 à 500 documents par seconde et traiter de l’ordre de 10 requêtes par seconde. Seul SharePoint Server 2016 prend en charge cette architecture de recherche de taille. Si vous avez jusqu’à 500 millions d’articles, une batterie similaire à la batterie de recherche très grande est un bon point de départ. Avec un taux d’analyse de 500 documents par seconde, la recherche prend environ 300 heures pour analyser 500 millions d’éléments dans la première analyse complète.
La création d’une batterie de recherche de cette taille vous oblige à planifier et paramétrer soigneusement la batterie pour obtenir les performances souhaitées. Vous trouverez peut-être avantageux de demander l’aide d’un expert. Il est également important de planifier la sauvegarde et la restauration d’une batterie de recherche de cette taille, et comment la récupérer si votre centre de données est en panne majeure. Nous vous recommandons de pratiquer la sauvegarde, la restauration et la récupération.
Étape 3 : De quelle configuration matérielle requise dois-je tenir compte ?
Maintenant que vous avez déterminé le volume de votre contenu et choisi une nouvelle topologie vers laquelle passer, l’étape suivante consiste à planifier le matériel dont vous aurez besoin, comme décrit dans cette section :
Choisir d’exécuter des serveurs physiques ou virtuels
Lorsque vous avez initialement planifié votre architecture de recherche, vous avez décidé d'utiliser des serveurs physiques, des machines virtuelles, ou un mélange des deux. Demandez-vous si cette décision est toujours valide. Par exemple, si vous passez de l’architecture de recherche moyenne à l’architecture de recherche d’exemple volumineuse, vous trouverez peut-être plus facile de gérer l’augmentation du nombre de serveurs lorsque vous utilisez des machines virtuelles. Notez également que même si un environnement virtuel est plus facile à gérer, son niveau de performances peut parfois être légèrement plus faible que celui d'un environnement physique. Un serveur physique peut héberger plus de composants de recherche sur le même serveur qu'un serveur virtuel. Vous trouverez des conseils utiles ici : Overview of farm virtualization and architectures for SharePoint 2013.
Les exemples d’architecture de recherche de petite, moyenne, grande ou très grande s’exécutent sur des machines virtuelles, mais ils peuvent également s’exécuter sur des serveurs physiques. Dans les exemples d’architectures de batterie, déplacez simplement les composants de recherche depuis les machines virtuelles vers le serveur hôte et enlevez les machines virtuelles. Chaque serveur physique peut héberger jusqu’à quatre composants d’index, mais seulement un de chaque type des autres composants de recherche. Si, par exemple, vous modifiez l’architecture de recherche de l’exemple moyen pour utiliser des serveurs physiques, vous constaterez que vous disposez de deux composants de traitement de contenu sur l’hôte E. La solution consiste à enlever l’un des composants de traitement du contenu. Cela fonctionne, car l’analyse, le traitement du contenu et le traitement de l’analytique dépendent de la quantité de ressources disponibles, et non du nombre de composants de traitement du contenu.
Choisir les ressources matérielles pour les serveurs hôtes
Chaque composant de recherche et base de données de recherche a besoin d’une quantité minimale de ressources matérielles du serveur hôte pour fonctionner correctement. Cependant, plus vous avez de ressources matérielles, plus les performances de votre architecture de recherche seront bonnes. Il est donc judicieux de disposer de plus de ressources matérielles que le minimum requis. Les ressources que chaque composant de recherche exige dépendent de la charge de travail, qui est la plupart du temps déterminée par le taux d'analyse, le taux de requête et le nombre d'éléments indexés.
Par exemple, en cas d'hébergement de machines virtuelles sur Windows Server 2008 R2 Service Pack 1 (SP1), vous ne pouvez pas utiliser plus de quatre cœurs de processeur par machine virtuelle. Avec Windows Server 2012 ou une version ultérieure, vous utilisez au moins huit cœurs de processeur par machine virtuelle. Vous pouvez alors effectuer une mise à l'échelle horizontale avec plus de cœurs de processeur pour chaque machine virtuelle au lieu d'effectuer une mise à l'échelle verticale avec plus de machines virtuelles. Configurez des serveurs ou des machines virtuelles qui hébergent les mêmes composants de recherche, avec les mêmes ressources matérielles. Prenons le composant d'index comme exemple. Lorsque vous hébergez des partitions d'index sur des machines virtuelles, la machine virtuelle ayant les performances les plus faibles détermine les performances de l'architecture de recherche globale.
Ressources de stockage générales
Assurez-vous que chaque serveur hôte dispose de suffisamment d’espace disque pour l’installation de base du système d’exploitation Windows Server et pour les fichiers programme SharePoint Server. Le serveur hôte doit aussi disposer d'un espace disque supplémentaire pour les fonctions de diagnostic, telles que la journalisation, le débogage et la création de fichiers de vidage de la mémoire, pour les opérations quotidiennes et pour le fichier d'échange. Normalement, 80 Go d’espace disque sont suffisants pour le système d’exploitation Windows Server et pour les fichiers programme SharePoint Server.
Ajoutez du stockage pour l'espace du journal SQL de chaque serveur de base de données. Si vous ne définissez pas le serveur de base de données pour sauvegarder les bases de données régulièrement, l'espace du journal SQL utilise beaucoup de stockage. Pour plus d'informations sur le mode de planification des bases de données SQL, voir Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server).
Le stockage minimal requis par la base de données de rapports d’analytique peut varier. En effet, la quantité de stockage dépend de la façon dont les utilisateurs interagissent avec SharePoint Server. Lorsque les utilisateurs interagissent fréquemment, il y a généralement plus d’événements à stocker. Vérifiez la quantité de stockage utilisée par votre architecture de recherche actuelle pour la base de données d’analyse et affectez au moins cette quantité à votre topologie repensée.
Ressources matérielles minimales pour la batterie de recherche de petite taille
Ce tableau indique la quantité minimale de ressources matérielles dont a besoin chaque serveur d'applications ou serveur de bases de données.
| Serveur | Hôte | Stockage | RAM | Processeur1 | Bande passante réseau |
|---|---|---|---|---|---|
| Serveur d'applications avec composants d'index et de traitement des requêtes. | A, B | 500 Go2,3 | 32 Go2,3 | 1,8 GHz 8 cœurs de processeur2,3 | 1 Gbit/s |
| Serveur d'applications avec composants de traitement analytique et de contenu, d'administration de la recherche et d'analyse. | A, B | 200 Go | 8 Go | 1,8 GHz 4 cœurs d’UC | 1 Gbit/s |
| Serveur de bases de données avec toutes les bases de données de recherche. | C, D | 100 Go | 16 Go | 1,8 GHz 4 cœurs d’UC | 1 Gbit/s |
1Le nombre de cœurs d’UC est spécifié ici, pas le nombre de threads d’UC.
deuxAvec SharePoint Server 2013, la quantité minimale de ressources nécessaires est de 500 Go de stockage, 16 Go de RAM et quatre cœurs de processeur.
3Avec SharePoint Server 2016, vous pouvez également utiliser 250 Go de stockage, 16 Go de RAM et quatre cœurs de processeur, mais chaque composant d’index ne peut contenir que 10 millions d’éléments et la batterie de serveurs de recherche prend uniquement en charge le même volume de contenu qu’une batterie de serveurs de recherche SharePoint Server 2013.
Ressources matérielles minimales pour la batterie de recherche de taille moyenne
Ce tableau indique la quantité minimale de ressources matérielles dont a besoin chaque serveur d'applications ou serveur de bases de données.
| Serveur | Hôte | Stockage | RAM | Processeur1 | Bande passante réseau |
|---|---|---|---|---|---|
| Serveur d'applications avec composants d'index et de traitement des requêtes . | A, B, C, D | 500 Go2,3 | 32 Go2,3 | 1,8 GHz 8 cœurs de processeur2,3 | 1 Gbit/s |
| Serveur d'applications avec un composant d'index. | A, B, C, D | 500 Go2,3 | 32 Go2,3 | 1,8 GHz 8 cœurs de processeur2,3 | 1 Gbit/s |
| Serveur d'applications avec composants de traitement analytique et de contenu. | E, F | 300 Go | 8 Go | 1,8 GHz 4 cœurs d’UC | 1 Gbit/s |
| Serveur d'applications avec composants de traitement de contenu, d'administration de la recherche et d'analyse. | E, F | 100 Go | 8 Go | 1,8 GHz 4 cœurs d’UC | 1 Gbit/s |
| Serveur de bases de données avec toutes les bases de données de recherche. | G, H | 400 Go | 16 Go | 1,8 GHz 4 cœurs d’UC | 1 Gbit/s |
1Le nombre de cœurs d’UC est spécifié ici, pas le nombre de threads d’UC.
deuxAvec SharePoint Server 2013, la quantité minimale de ressources nécessaires est de 500 Go de stockage, 16 Go de RAM et quatre cœurs de processeur.
3Avec SharePoint Server 2016, vous pouvez également utiliser 250 Go de stockage, 16 Go de RAM et quatre cœurs de processeur, mais chaque composant d’index ne peut contenir que 10 millions d’éléments et la batterie de serveurs de recherche prend uniquement en charge le même volume de contenu qu’une batterie de serveurs de recherche SharePoint Server 2013.
Ressources matérielles minimales pour la batterie de recherche de grande taille
Ce tableau indique la quantité minimale de ressources matérielles dont a besoin chaque serveur d'applications ou serveur de bases de données.
| Serveur | Hôte | Stockage | RAM | Processeur1 | Bande passante réseau |
|---|---|---|---|---|---|
| Serveur d'applications avec composants d'index et de traitement des requêtes . | A, B, C, D, E, G, H | 500 Go2,3 | 32 Go2,3 | 1,8 GHz 8 cœurs de processeur2,3 | 1 Gbit/s |
| Serveur d'applications avec un composant d'index. | A, B, C, D, E, F, G, H, I, J | 500 Go2,3 | 32 Go2,3 | 1,8 GHz 8 cœurs de processeur2,3 | 1 Gbit/s |
| Serveurs d'applications avec composants de traitement analytique et de contenu. | K, L, M, N | 300 Go | 8 Go | 1,8 GHz 4 cœurs d’UC | 1 Gbit/s |
| Serveurs d'applications avec composants d'administration de la recherche et d'analyse. | K, L | 100 Go | 8 Go | 1,8 GHz 4 cœurs d’UC | 1 Gbit/s |
| Serveurs contenant des bases de données de recherche. | O, P, Q, R | 500 Go | 16 Go | 1,8 GHz 4 cœurs d’UC | 1 Gbit/s |
deuxAvec SharePoint Server 2013, la quantité minimale de ressources nécessaires est de 500 Go de RAM, 16 Go de RAM et quatre cœurs de processeur.
3Avec SharePoint Server 2016, vous pouvez également utiliser 250 Go de stockage, 16 Go de RAM et quatre cœurs de processeur, mais chaque composant d’index ne peut contenir que 10 millions d’éléments et la batterie de serveurs de recherche prend uniquement en charge le même volume de contenu qu’une batterie de serveurs de recherche SharePoint Server 2013.
Ressources matérielles minimales pour la batterie de serveurs de recherche très volumineuse
Ce tableau indique la quantité minimale de ressources matérielles dont a besoin chaque serveur d'applications ou serveur de bases de données. Vous pouvez uniquement générer cet exemple de batterie avec SharePoint Server 2016.
| Serveur | Hôte | Stockage | RAM | Processeur1 | Bande passante réseau |
|---|---|---|---|---|---|
| Serveur d’applications qui a des composants d’index. | A-X | 500 Go | 32 Go | 1,8 GHz 8 cœurs de processeur x | 1 Gbit/s |
| Serveur d'applications avec composants d'index et de traitement des requêtes . | Y, Z | 500 Go | 32 Go | 1,8 GHz 8 cœurs de processeur x | 1 Gbit/s |
| Serveurs d’applications qui ont des composants d’analyse, d’administration de recherche ou de traitement du contenu | AA-AF | 100 Go | 8 Go | 1,8 GHz 4 cœurs d’UC | 1 Gbit/s |
| Serveurs d’applications qui ont des composants de traitement d’analytique | AG, AH | 800 Go | 8 Go | 1,8 GHz 4 cœurs d’UC | 1 Gbit/s |
| Serveurs de base de données qui ont des bases de données de recherche | AI-AL | 500 Go | 16 Go | 1,8 GHz 4 cœurs d’UC | 1 Gbit/s |
1Le nombre de cœurs d’UC est spécifié ici, pas le nombre de threads d’UC.
Planifier les performances de stockage
La vitesse du stockage a une incidence sur les performances de recherche. Veillez à ce que le stockage dont vous disposez soit assez rapide pour gérer le trafic provenant des bases de données et des composants de recherche. La vitesse du disque est mesurée en opérations d'E/S par seconde (IOPS).
La façon dont vous décidez de distribuer les données provenant des composants de recherche et du système d'exploitation dans l'ensemble de votre stockage influe sur les performances de recherche. Il est conseillé d'effectuer les actions suivantes :
Fractionnez les fichiers du système d’exploitation Windows Server, les fichiers programme SharePoint Server et les journaux de diagnostic sur trois volumes de stockage ou partitions distincts avec des performances normales.
Stocker les données de composant de recherche sur un volume ou une partition de stockage distinct. Pour les composants d'index, ce stockage doit également avoir des performances élevées.
Notes
Vous pouvez définir un emplacement personnalisé pour les données de composant de recherche lorsque vous installez SharePoint Server sur un hôte. Tous les composants de recherche sur l'hôte qui doivent stocker des données le font à cet emplacement. Pour modifier cet emplacement ultérieurement, vous devez réinstaller SharePoint Server.
Choisir le type de stockage
Pour obtenir une vue d'ensemble des architectures de stockage et des types de disques, voir Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server 2013). Les serveurs qui hébergent les composants d'index, de traitement analytique et d'administration de la recherche, ou les bases de données de recherche, requièrent un stockage capable de maintenir une latence faible, tout en permettant de réaliser un nombre suffisant d'opérations d'E/S par seconde (IOPS). Les tableaux suivants indiquent le nombre d'IOPS que chacun de ces composants et bases de données de recherche requièrent.
Si vous déployez un stockage partagé de type SAN/NAS, la charge disque maximale d'un composant de recherche coïncide généralement avec la charge disque maximale d'un autre composant de recherche. Pour obtenir le nombre d’IOPS requises par la recherche dans le cas d’un stockage partagé, vous devez ajouter les besoins en IOPS de chacun de ces composants.
Besoins en IOPS des composants de recherche
| Nom du composant | Détails du composant | Besoins en IOPS | Utilisation de volume/partition de stockage distinct |
|---|---|---|---|
| Composant d'index | Utilise le stockage lors de la fusion de l’index et lors de la gestion et de la réponse aux requêtes. | 300 IOPS pour 64 Ko de lectures aléatoires 100 IOPS pour 256 Ko d’écritures aléatoires 200 Mo/s pour les lectures séquentielles 200 Mo/s pour les écritures séquentielles |
Oui |
| Composant analytique | Analyse les données localement, en traitement en bloc. | Non | Oui |
| Composant d'analyse | Stocke le contenu téléchargé localement, avant de l'envoyer à un composant de traitement de contenu. Le stockage est limité par la bande passante réseau. | Non | Oui |
Besoins en IOPS des bases de données de recherche
| Nom de la base de données | Besoins en IOPS | Charge classique sur le sous-système d'E/S |
|---|---|---|
| Base de données d'analyse | IOPS moyennes à élevées | 10 IOPS pour un taux d’analyse d’1 document par seconde (DPS) |
| Base de données de liens | IOPS moyennes | 10 IOPS pour 1 million d’éléments dans l’index de recherche |
| Base de données d'administration de la recherche | IOPS faibles | Non applicable |
| Base de données de création de rapports d'analyse | IOPS moyennes | Non applicable |
Choisir le mode de prise en charge de la haute disponibilité dans votre architecture de recherche
Si vous connaissez peu les stratégies de haute disponibilité, voici un article qui vous permettra de démarrer : Créer une architecture et une stratégie haute disponibilité pour SharePoint Server. Lorsque vous hébergez des composants et des bases de données de recherche redondants sur des domaines d'erreur distincts, une panne dans une partie de la batterie de serveurs n'arrête pas l'ensemble du service. Cependant, étant donné que les composants de recherche ne peuvent plus partager la charge, les performances de la recherche se dégradent. Pour réduire le risque de perdre un seul serveur, il est judicieux d’améliorer la redondance locale. Pour chaque serveur hôte dans votre architecture de recherche :
Utilisez le stockage RAID sur chaque serveur.
Installez plusieurs connexions réseau redondantes sur chaque serveur.
Installez plusieurs alimentations redondantes avec un câblage indépendant ou un bloc d’alimentation sans interruption (OND) pour chaque serveur.
Tous les échantillons d'architecture de recherche hébergent des composants de recherche redondants sur des serveurs indépendants. Dans les échantillons d'architecture de recherche, l'hôte le plus à droite dans chaque paire d'hôtes est redondant. Voici l'architecture de recherche de grande taille avec un contour autour des hôtes redondants :
