Reconcevoir la topologie de recherche de contenu d’entreprise pour plus de contenu et d’utilisateurs dans SharePoint 2016

 

**Sapplique à :**SharePoint Server 2016

**Dernière rubrique modifiée :**2017-09-08

Résumé : Découvrez comment reconcevoir la topologie de votre architecture de recherche de contenu d’entreprise pour prendre en charge l’augmentation du volume de contenu, du nombre d’utilisateurs ou les deux.

Au fil du temps, la plupart des environnements de recherche se développent, à la fois quant au volume de contenu et au nombre d’utilisateurs. À un moment donné, l’environnement de recherche atteint une taille trop importante pour la capacité et les performances de votre architecture de recherche. La solution est donc de mettre à l’échelle la topologie de votre architecture de recherche :

1. ABL Reconcevez votre topologie (voir le présent article).

2. 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 étape par étape comment reconcevoir votre topologie de recherche.

• Étape 1 : Quel est le volume de contenu dont je dispose ?

• Étape 2 : Quelle taille faut-il attribuer à l'architecture de recherche ?

• É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 inclus dans votre index de recherche influe sur les ressources dont vous avez besoin pour héberger la batterie de serveurs. Vérifiez le nombre d’éléments pouvant faire l’objet d’une recherche dans votre environnement de recherche existant. Vous trouverez ce nombre sur la page Administration de la recherche sur le site web le site Web Administration centrale de SharePoint. Pour ouvrir la page d’administration de la recherche, cliquez sur Gérer les applications de service dans Administration centrale, puis cliquez sur le nom de l’application Service de recherche.

Estimez l’augmentation prévue du nombre d’éléments pouvant faire l’objet d’une recherche au cours des douze prochains mois et concevez la topologie de recherche en conséquence. Par exemple, si vous avez 8 000 000 d’éléments indexés et que vous prévoyez une augmentation du volume de contenu de 50 % au cours des douze prochains mois, vous devez concevoir la topologie pour 12 000 000 d’éléments pouvant faire l’objet d’une recherche.

Étape 2 : Quelle taille faut-il attribuer à l’architecture de recherche ?

Il n’est pas toujours facile d’évaluer la taille à attribuer à votre architecture de recherche. Elle dépend du volume de contenu, de la vitesse d’analyse, du débit des requêtes et du niveau de haute disponibilité dont vous avez besoin. Des exemples d’architectures de recherche ont été testés par Microsoft, et nous vous conseillons de les utiliser comme base pour votre propre batterie de serveurs. Comparez votre architecture de recherche actuelle à ces exemples et déterminez lequel s’en approche le plus. Réfléchissez ensuite à l’exemple d’architecture de recherche sur lequel vous baser pour la mise à l’échelle. Choisissez-le selon le volume de contenu qui doit pouvoir 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’éléments	Batterie de recherche de petite taille	0 à 10 millions d’éléments
0 à 80 millions d’éléments	Batterie de recherche de taille moyenne	0 à 40 millions d’éléments
0 à 200 millions d’éléments	Batterie de recherche de grande taille	0 à 100 millions d’éléments
0 à 500 millions d’éléments	Batterie de recherche de très grande taille	Non pris en charge

Même si ces exemples d’architectures de recherche utilisent des machines virtuelles, vous pouvez utiliser à la fois des serveurs physiques et des machines virtuelles selon la stratégie de la solution SharePoint Server globale de votre architecture de recherche.

Batterie de recherche de petite taille

Nous estimons que cette architecture de recherche permet d’analyser 50 documents par seconde et de répondre aux ordres de 10 requêtes par seconde. Si vous avez moins de 20 millions d’éléments dans une batterie SharePoint Server 2016, la batterie de recherche de petite taille est probablement la plus adaptée à vos besoins. Avec un taux d’analyse de 50 documents par seconde, une recherche de 110 heures est nécessaire pour analyser 20 millions d’éléments lors de la première analyse complète.

Batterie de recherche de taille moyenne

Nous estimons que cette architecture de recherche permet d’analyser 100 documents par seconde et de répondre aux ordres de 10 requêtes par seconde. Si vous disposez de 20 à 80 millions d’éléments dans une batterie SharePoint Server 2016, la batterie de recherche de taille moyenne est probablement la plus adaptée à vos besoins. Avec un taux d’analyse de 200 documents par seconde, une recherche de 280 heures est nécessaire pour analyser 80 millions d’éléments lors de la première analyse complète.

Batterie de recherche de grande taille

Nous estimons que cette architecture de recherche permet d’analyser 200 documents par seconde et de répondre aux ordres de 10 requêtes par seconde. Si vous disposez de 80 à 200 millions d’éléments dans une batterie SharePoint Server 2016, la batterie de recherche de grande taille est probablement la plus adaptée à vos besoins. Avec un taux d’analyse de 200 documents par seconde, une recherche de 280 heures est nécessaire pour analyser 200 millions d’éléments lors de la première analyse complète.

Batterie de recherche de très grande taille

Microsoft a testé cette architecture de recherche et a mesuré qu’elle permet d’analyser entre 300 et 500 documents par seconde et de répondre aux ordres de 10 requêtes par seconde. Seul SharePoint Server 2016 prend en charge les architectures de recherche de cette taille. Si vous avez jusqu’à 500 millions d’éléments, une batterie comparable à la batterie de recherche de très grande taille est un bon point de départ. Avec un taux d’analyse de 500 documents par seconde, une recherche de 300 heures est nécessaire pour analyser 500 millions d’éléments lors de la première analyse complète.

La création d’une batterie de recherche de cette taille nécessite de planifier et régler soigneusement la batterie afin d’obtenir les performances souhaitées. Des conseils d’experts peuvent être profitables. Il est également important de planifier la sauvegarde et la restauration d’une batterie de recherche de cette taille, ainsi que la récupération de la batterie si votre centre de données subit une panne importante. Nous vous recommandons de vous entraîner à exécuter des procédures de sauvegarde, de restauration et de récupération.

Étape 3 : De quelle configuration matérielle requise dois-je tenir compte ?

Maintenant que vous avez déterminé le volume de contenu et choisi une nouvelle topologie à définir, la prochaine étape consiste à prévoir le matériel dont vous avez besoin, comme décrit dans cette section :

• Choisir d'exécuter des serveurs physiques ou virtuels

• Choisir les ressources matérielles pour les serveurs hôtes

  • Stockage global

  • Ressources matérielles minimales pour la batterie de recherche de petite taille

  • Ressources matérielles minimales pour la batterie de recherche de taille moyenne

  • Ressources matérielles minimales pour la batterie de recherche de grande taille

• Planifier les performances de stockage

  • Choisir le type de stockage

  • Besoins en IOPS des composants de recherche

  • Besoins en IOPS des bases de données de recherche

• Choisir le mode de prise en charge de la haute disponibilité dans votre architecture de recherche

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 une combinaison des deux. Demandez-vous si cette décision est toujours judicieuse. Par exemple, si vous passez de l’exemple d’architecture de recherche de taille moyenne à l’exemple d’architecture de recherche de grande taille, vous trouverez peut-être plus facile de gérer l’augmentation du nombre de serveurs en utilisant des ordinateurs virtuels. Remarquez également que, bien qu’un environnement virtuel soit plus facile à gérer, son niveau de performances peut parfois s’avérer légèrement plus faible que celui d’un environnement physique. Un serveur physique peut héberger plus de composants de recherche qu’un serveur virtuel. Vous trouverez des conseils utiles dans l’article Vue d’ensemble des architectures et de la virtualisation de batterie de serveurs pour SharePoint 2013.

Les exemples d’architectures de recherche de taille petite, moyenne, grande ou très grande fonctionnent sur des machines virtuelles et aussi sur des serveurs physiques. Dans l’exemple d’architecture de batterie de serveurs, il suffit de déplacer les composants de recherche des machines virtuelles sur le serveur hôte et d’enlever 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. Par exemple, si vous modifiez l’exemple d’architecture de recherche de taille moyenne pour utiliser des serveurs physiques, vous vous apercevrez que vous avez deux composants de traitement du contenu sur l’hôte E. La solution consiste à enlever un des composants de traitement du contenu. Cela fonctionne car l’analyse, le traitement du contenu et le traitement de l’analyse dépendent de la quantité de ressources disponibles, et non du nombre de composants affectés à cette tâche.

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

Veillez à ce que chaque serveur hôte dispose d’un espace disque suffisant pour l’installation de base du système d’exploitation Windows Server et des fichiers de 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 de 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 nécessaire pour la base de données de création de rapports d’analyse peut varier, car la quantité de stockage dépend de la façon dont les utilisateurs interagissent avec SharePoint Server. Lorsque les utilisateurs interagissent souvent, 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 redéfinie.

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	Mémoire RAM	Processor1	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 d’UC2,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.

2Avec SharePoint Server 2013 la quantité minimale de ressources requises est de 500 Go de RAM, 16 Go de RAM et quatre cœurs d’UC.

3Avec SharePoint Server 2016 vous pouvez également utiliser un espace de stockage de 500 Go, 16 Go de RAM et quatre cœurs d’UC, 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 SharePoint Server 2013 batterie de serveurs de recherche.

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	Mémoire RAM	Processor1	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 d’UC2,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 d’UC2,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.

2Avec SharePoint Server 2013 la quantité minimale de ressources requises est de 500 Go de RAM, 16 Go de RAM et quatre cœurs d’UC.

3Avec SharePoint Server 2016 vous pouvez également utiliser un espace de stockage de 500 Go, 16 Go de RAM et quatre cœurs d’UC, 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 SharePoint Server 2013 batterie de serveurs de recherche.

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	Mémoire RAM	Processor1	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 d’UC2,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 d’UC2,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

2Avec SharePoint Server 2013 la quantité minimale de ressources requises est de 500 Go de RAM, 16 Go de RAM et quatre cœurs d’UC.

3Avec SharePoint Server 2016 vous pouvez également utiliser un espace de stockage de 500 Go, 16 Go de RAM et quatre cœurs d’UC, 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 SharePoint Server 2013 batterie de serveurs de recherche.

Ressources matérielles minimales pour la batterie de recherche de très 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. Vous pouvez seulement créer cette batterie d’échantillon avec SharePoint Server 2016.

Serveur	Hôte	Stockage	Mémoire RAM	Processor1	Bande passante réseau
Serveur d’applications avec des composants d’index.	A-X	500 Go	32 Go	1,8 GHz 8 cœurs d’UC	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 d’UC	1 Gbit/s
Serveurs d’applications avec composants de traitement de contenu, d’administration de la recherche ou d’analyse.	AA-AF	100 Go	8 Go	1,8 GHz 4 cœurs d’UC	1 Gbit/s
Serveurs d’applications avec composants de traitement de l’analyse.	AG, AH	800 Go	8 Go	1,8 GHz 4 cœurs d’UC	1 Gbit/s
Serveurs de base de données contenant 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 :

• Fractionner les fichiers du système d’exploitation de Windows Server, les fichiers de programme de SharePoint Server et les journaux de diagnostic en trois volumes ou partitions de stockage 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 par la suite, 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 de défaillance distincts, une panne dans une partie de la batterie de serveurs n’arrête pas l’ensemble du service. Toutefois, étant donné que les composants de recherche ne peuvent plus partager la charge, les performances de 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 de 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 onduleur 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 :