Planifier la recherche de contenu d’entreprise globale

Mise à jour : 2009-04-23

Dans cet article :

• Architectures de recherche recommandées

• Recherche centralisée

• Fournisseurs SSP régionaux avec un contenu synchronisé

• Recherche centralisée et recherche distribuée

• Recherche distribuée

• Recherche fédérée

Architectures de recherche recommandées

Si vous envisagez de déployer plusieurs batteries de serveurs exécutant Microsoft Office SharePoint Server 2007 géographiquement, il existe plusieurs architectures de recherche qui sont pratiques pour les environnements WAN (Wide Area Network). Cet article décrit ces architectures. Le modèle de la taille d’un poster suivant fournit une vue d’ensemble des solutions globales prises en charge et des architectures de recherche recommandées : Déploiement de Microsoft Office SharePoint Server géographiquement (en anglais) (https://go.microsoft.com/fwlink/?linkid=110982&clcid=0x40C) (en anglais) . Ce modèle a été créé dans Microsoft Office Visio. Si Visio n’est pas installé sur votre système, vous pouvez télécharger une visionneuse gratuite (https://go.microsoft.com/fwlink/?linkid=73526&clcid=0x40C). Un traceur fonctionne mieux pour l’impression de ce fichier.

Remarque :
Ce poster n’est pas encore mis à jour avec les informations sur l’architecture de recherche fédérée.

La planification d’une architecture de recherche équilibre les types suivants de besoins en fonction des priorités d’une organisation :

• Expérience utilisateur dans la recherche de contenu à l’aide des requêtes de recherche. L’expérience de l’utilisateur inclut :

  • Les problèmes de performances liés à l’émission d’une requête de demande et à l’obtention des résultats de la recherche.

  • La pertinence et la précision des résultats qui sont retournés.

• Les problèmes de performances liés à l’analyse du contenu via un WAN.

• Le coût d’administration d’un environnement de recherche global.

Dans certains cas, comprendre les options d’architecture de recherche dans un environnement WAN peut aider à déterminer quelles sont les solutions globales prises en charge les plus appropriées pour votre organisation. Pour plus d’informations sur ces solutions, voir Solutions globales prises en charge pour Office SharePoint Server.

Cet article ne traite pas des caractéristiques des performances d’émission de requêtes de recherche via le WAN ou d’analyse du contenu via le WAN. Toutefois, comprendre dans quelle mesure votre environnement WAN prend en charge ces types d’opérations est essentiel pour la planification d’un environnement global. Pour plus d’informations sur le fonctionnement d’Office SharePoint Server 2007 via le WAN, voir Planifier la configuration requise pour la bande passante.

Recherche centralisée

Avec l’architecture de recherche centralisée, le service de recherche sur la batterie de serveurs centrale analyse le contenu de toutes les batteries de serveurs régionales. Les requêtes de recherche des utilisateurs régionaux sont envoyées à la batterie centrale.

La figure ci-dessous illustre une architecture de recherche centralisée.

Si les liaisons WAN prennent en charge l’analyse du contenu sur les sites régionaux, il s’agit de l’architecture recommandée, car elle fournit une expérience de recherche unifiée pour les utilisateurs qui inclut les aspects suivants :

• Les utilisateurs ont toujours accès à la batterie de serveurs centrale pour la recherche.

• La pertinence de la recherche est conservée dans les résultats de la recherche.

• Les utilisateurs peuvent effectuer des recherches sur tout le contenu à l’échelle de l’entreprise pour lequel ils disposent de l’autorisation d’affichage.

Un inconvénient de cette architecture, toutefois, est qu’il n’existe aucun moyen pour classer par ordre de priorité ou différencier le contenu local dans les résultats de la recherche, sauf si une zone de recherche est créée en fonction de l’emplacement du contenu de la batterie de serveurs. Autrement dit, si un utilisateur d’un site régional recherche un document stocké sur le site régional, il n’existe aucun moyen simple de distinguer où les documents résident lorsqu’ils sont répertoriés dans les résultats de la recherche.

Si les liaisons WAN ne fonctionnent pas bien, cette architecture peut introduire plusieurs risques. L’analyse du contenu peut surcharger une liaison WAN, ce qui peut altérer les performances de service des requêtes des utilisateurs. S’il existe un volume élevé de données avec un taux élevé de modifications, les travaux d’indexation ne pourront pas faire face aux modifications. Toutefois, vous pouvez optimiser Office SharePoint Server 2007 afin d’améliorer l’analyse du contenu via un WAN. Ces optimisations peuvent réduire le temps et le trafic réseau utilisés durant le processus d’indexation. Pour plus d’informations, voir « Optimisation pour l’analyse du contenu » dans Optimisation d’Office SharePoint Server pour des environnements de réseau étendu.

Enfin, bien que les liaisons WAN affectent la possibilité d’analyse du contenu à distance, et par conséquent la possibilité d’utiliser l’architecture de recherche centralisée, des liaisons WAN plus lentes peuvent également jouer un rôle dans l’utilisation de la recherche pour les utilisateurs régionaux. La lenteur des liaisons WAN peut décourager les utilisateurs d’émettre des requêtes. Vous pouvez optimiser les performances du réseau étendu pendant les heures de travail en planifiant l’analyse du contenu et d’autres opérations qui peuvent diminuer les performances pendant les heures creuses. Même avec l’optimisation, cependant, vous devez déterminer si l’architecture de recherche centralisée sert correctement les besoins des utilisateurs régionaux via les liaisons WAN existantes.

Dans de nombreux cas, proposer l’architecture de recherche centralisée aide à faire monter en charge Office SharePoint Server 2007 afin de fournir des services aux utilisateurs régionaux.

Le tableau ci-dessous récapitule les avantages et les inconvénients de l’architecture de recherche centralisée.

Avantages	Inconvénients
La pertinence de la recherche est conservée. La gestion des fournisseurs SSP est centralisée.	L’analyse du contenu via le réseau étendu utilise la bande passante. Maintenir les index à jour peut être difficile dans des environnements avec des volumes importants de données et un taux de modifications élevé. La performance des requêtes est soumise à la performance des liaisons WAN.

Fournisseurs SSP régionaux avec un contenu synchronisé

Si les liaisons WAN ne prennent pas en charge l’architecture de recherche centralisée et vous souhaitez fournir la recherche en tant que service à des sites régionaux, vous pouvez héberger un SSP sur chaque site régional.

Il existe plusieurs architectures de recherche différentes qui impliquent l’hébergement des fournisseurs SSP sur les sites régionaux. La première de ces architectures repose sur la synchronisation du contenu au sein de votre organisation pour que chaque site régional dispose d’une copie de tout le contenu nécessaire aux travailleurs sur ce site régional. Cette approche de gestion du contenu dans une organisation globale est décrite dans Concevoir l’architecture globale des informations et le plan de gouvernance. Le contenu étant synchronisé, il n’est pas nécessaire de l’analyser à distance sur le réseau étendu.

La figure ci-dessous illustre cette architecture.

Dans la figure :

• Les projets prêts à être partagés à l’échelle de l’entreprise sont publiés sur le site central, sans tenir compte de l’emplacement dans lequel le contenu est créé.

• Une fois le contenu publié sur le site central, les versions en lecture seule des projets sont synchronisées sur tous les sites.

• Le service de recherche de chaque batterie de serveurs analyse uniquement le contenu de la batterie de serveurs.

De même, les informations sur la société sont synchronisées dans toute l’organisation de la même façon, comme illustré dans la figure ci-dessous.

Bien que cette architecture évite d’avoir à analyser le contenu sur le réseau étendu, elle nécessite l’utilisation de liaisons réseau étendu pour synchroniser le contenu dans l’environnement. Pour réduire l’effet sur les performances réseau étendu (WAN), vous pouvez planifier ces opérations pendant les heures creuses. Le principal avantage est que les utilisateurs régionaux ont accès au contenu local à l’aide du service de recherche local. Étant donné cette architecture, l’utilisation de liaisons réseau étendu est planifiée et gérée, et les utilisateurs ne sont pas perturbés par les performances de ces liaisons lors de l’exécution de leurs tâches.

Le tableau ci-dessous récapitule les avantages et les inconvénients de cette architecture de recherche.

Avantages	Inconvénients
Le contenu est analysé localement. Les performances des requêtes de recherche ne sont pas soumises aux performances des liaisons réseau étendu. La pertinence de la recherche est conservée dans chaque batterie de serveurs.	Plusieurs fournisseurs SSP augmentent les coûts d’administration. La synchronisation du contenu au sein d’une organisation augmente la complexité de la solution.

Recherche centralisée et recherche distribuée

Vous pouvez concevoir une architecture de recherche qui combine recherche centralisée et recherche distribuée. Avec cette architecture, le service de recherche de chaque région analyse tout le contenu de cette région et la batterie de serveurs centrale analyse le contenu de toutes les batteries de serveurs de l’organisation.

Grâce à cette architecture, les utilisateurs régionaux peuvent rechercher du contenu local sans utiliser les liaisons réseau étendu (WAN). Les utilisateurs régionaux peuvent rechercher à l’échelle de l’entreprise globale en émettant des requêtes sur la batterie de serveurs centrale.

La figure ci-dessous illustre l’architecture de recherche centralisée et de recherche distribuée.

Dans le schéma :

• Chaque batterie de serveurs héberge un fournisseur SSP. Le service de recherche fourni par le fournisseur SSP local analyse le contenu local de chaque batterie de serveurs régionale.

• Le service de recherche fourni par le fournisseur SSP de la batterie centrale analyse également le contenu des batteries régionales.

Le principal avantage de cette architecture est que les performances de la requête sont optimisées pour le contenu local tandis que la recherche globale est fournie en tant qu’option. Cette architecture fonctionne bien dans les conditions suivantes :

• Les travailleurs régionaux utilisent la recherche principalement pour accéder au contenu local.

• Les liaisons WAN prennent en charge l’analyse du contenu sur les sites régionaux.

Bien qu’étant semblable à l’architecture de recherche centrale, cette architecture repose sur la forte utilisation de liaisons réseau étendu pour l’analyse du contenu. Toutefois, avec la recherche locale en tant qu’option, le moteur de recherche globale ne joue pas un rôle critique dans l’architecture de recherche globale, et vous pouvez factoriser cela dans des planifications d’analyse et des accords de niveau de service.

Le tableau ci-dessous récapitule les avantages et les inconvénients de cette architecture de recherche.

Avantages	Inconvénients
Les performances de la requête sont optimisées pour le contenu local. Cette option réduit considérablement le nombre de requêtes sur le réseau étendu par rapport au modèle de recherche centralisée. La pertinence de la recherche est optimisée selon l’étendue de la recherche (locale ou globale).	Plusieurs fournisseurs SSP augmentent les coûts d’administration. L’analyse du contenu via le réseau étendu utilise la bande passante. Pour les utilisateurs régionaux qui effectuent des requêtes globales, les performances des requêtes sont affectées par les performances des liaisons réseau étendu.

Recherche distribuée

Si les liaisons WAN ne prennent pas en charge la synchronisation du contenu dans un environnement global ou l’analyse du contenu distant sur les batteries de serveurs régionales, vous pouvez fournir la recherche uniquement au niveau de la batterie de serveurs régionale. Avec l’architecture de recherche distribuée, chaque batterie de serveurs régionale héberge son propre fournisseur SSP, et le service de recherche qui est fourni par chaque SSP régional analyse le contenu local uniquement.

La figure ci-dessous illustre l’architecture de recherche distribuée.

Envisagez d’implémenter l’architecture de recherche distribuée dans les conditions suivantes :

• Les sites régionaux ne sont pas correctement connectés avec les liaisons réseau étendu (WAN).

• Les sites régionaux sont autonomes par rapport aux autres sites régionaux.

• Les sites régionaux ne s’appuient pas fortement sur une connexion au site central, par exemple, une organisation avec des succursales qui fonctionnent de façon autonome.

• Il existe un grand nombre de sites régionaux, et le modèle d’entreprise et les liaisons WAN ne prennent pas en charge un modèle centralisé, par exemple, une organisation comportant un grand nombre de succursales qui ne sont pas bien connectées par des liaisons réseau étendu (WAN).

Le tableau ci-dessous récapitule les avantages et les inconvénients de l’architecture de recherche distribuée.

Avantages	Inconvénients
La pertinence de la recherche est conservée. Le contenu n’est pas analysé sur des liaisons réseau étendu (WAN).	La recherche n’est pas à l’échelle de l’entreprise. Les utilisateurs sur les batteries de serveurs régionales doivent se connecter à la batterie centrale pour rechercher du contenu de cette batterie de serveurs.

Recherche fédérée

La recherche fédérée est une fonctionnalité ajoutée à la Mise à jour d’infrastructure pour les produits serveur de Microsoft Office. Cette fonctionnalité est également incluse dans Microsoft Search Server 2008. La recherche fédérée permet aux utilisateurs finaux d’émettre une requête qui effectue une recherche dans différentes sources et affiche les résultats dans des composants WebPart distincts sur une page de résultats de recherche unique. Ces sources peuvent être des référentiels de contenu de l’entreprise, d’autres moteurs de recherche ou des parties de l’index du serveur de recherche. L’utilisation de la fédération permet d’offrir aux utilisateurs des résultats de requête plus complets sans qu’il soit nécessaire de dédier les ressources serveur à l’analyse et à l’indexation du contenu.

Dans un environnement distribué comportant des batteries de serveurs dans différentes régions, la recherche fédérée peut être configurée sur chacune des régions représentant un emplacement fédéré spécifique. Les résultats de recherche de chaque région apparaissent à l’utilisateur dans un composant WebPart de résultats fédérés spécifique. Les résultats peuvent être affichés dès leur réception. Par exemple, les résultats de recherche issus de la batterie de serveurs locale sont susceptibles d’être retournés avant les résultats de recherche reçus sur des connexions WAN.

Le schéma suivant illustre l’utilisation de la recherche fédérée dans un environnement distribué géographiquement dans lequel Microsoft Office SharePoint Server est déployé sur chaque région.

Caractéristiques de ce schéma :

• Un utilisateur de la batterie de serveurs régionale 2 émet une requête.

• Le trafic généré par la requête est envoyé à un serveur Web appartenant à la batterie de serveurs locale. Le serveur Web transmet la requête aux emplacements de recherche fédérée.

• Les requêtes A et B destinées à des emplacements fédérés et sont envoyées aux batteries de serveurs distribuées géographiquement.

• La requête C est une recherche locale traitée par la batterie de serveurs locale.

• Les résultats de la recherche sont affichés dans une page Web dans différents composants WebPart.

Configuration de la recherche fédérée dans les environnements distribués

À l’aide de la recherche fédérée, chaque batterie de serveurs analyse son propre contenu. Dans le cas des batteries de serveurs exécutant Office SharePoint Server, un fournisseur de services partages est nécessaire sur chaque batterie de serveurs régionale. Vous créez une connexion fédérée à une batterie de serveurs distante exécutant Office SharePoint Server en créant (sur la batterie de serveurs locale) un emplacement OpenSearch fédéré. L’emplacement OpenSearch fédéré doit pointer vers le flux RSS d’une page de résultats de recherche dans un centre de recherche sur la batterie de serveurs distante. Vous devez inclure la batterie de serveurs locale dans la recherche fédérée en créant un emplacement fédéré de type « index de recherche locale ». Pour implémenter la recherche fédérée dans un environnement distribué, configurez chaque batterie de serveurs avec des emplacements fédérés pour les autres batteries de serveurs.

Le schéma suivant illustre en détail une connexion de recherche fédérée à une batterie de serveurs distante.

Caractéristiques de ce schéma :

• Sur la batterie de serveurs centrale, un centre de recherche est ajouté à la collection de sites Company Info. Ce centre de recherche est configuré avec l’étendue qui permet aux utilisateurs d’effectuer une recherche sur l’ensemble de la batterie de serveurs. Ce centre de recherche comprend une page Résultats de la recherche. Un flux RSS est activé pour cette page.

• Sur la batterie de serveurs régionale, une connexion de recherche fédérée (légende A) est configurée de manière à se connecter à la page Résultats de la recherche de la batterie de serveurs centrale. Cela permet aux utilisateurs locaux situés à proximité de la batterie de serveurs régionale d’effectuer une recherche sur l’ensemble du contenu de la batterie de serveurs centrale.

Dans de nombreux environnements comportant plusieurs batteries de serveurs, la totalité du contenu d’une batterie de serveurs n’est pas systématiquement pertinente pour les utilisateurs situés à proximité des autres batteries de serveurs. Par exemple, les stratégies de l’entreprise d’une région spécifique peuvent ne concerner que cette région. S’il s’avère qu’un sous-ensemble de contenu est pertinent en termes de recherche pour les utilisateurs situés dans d’autres régions, créez une étendue sur la batterie de serveurs qui étend la recherche au sous-ensemble de contenu pertinent. Lorsque vous créez une connexion fédérée à la batterie de serveurs distante, connectez-vous au même flux RSS de la page Résultats de la recherche, mais ajoutez l’étendue en tant que paramètre URL. Par exemple : https://server/searchcenter/_layouts/srchrss.aspx?k={searchTerms}&s=<yourcustomscope>

Pour plus d’informations sur la mise en œuvre d’un centre de recherche, voir les articles suivants :

• Planifier les conditions d’utilisation de la recherche pour l’utilisateur final (Office SharePoint Server)

• Personnalisation du centre de recherche de l’entreprise (https://go.microsoft.com/fwlink/?linkid=120906&clcid=0x40C)

Lorsque vous avez terminé la création et la configuration des emplacements de recherche fédérée, vous devez connecter chacun d’eux à un composant WebPart de résultats fédérés pour que les utilisateurs puissent voir les résultats à partir de l’emplacement affichés dans un centre de recherche. Configurez un composant WebPart de résultats fédérés distinct pour chaque batterie de serveurs. Lorsque vous configurez les propriétés des composants WebPart de résultats fédérés, veillez à sélectionner l’option permettant d’afficher les résultats de façon asynchrone (il s’agit du paramètre par défaut). Grâce à ce paramètre, les résultats s’affichent dès leur réception et les utilisateurs n’ont pas besoin d’attendre des connexions plus lentes pour commencer à afficher les résultats. Par défaut, si le mode asynchrone n’est pas sélectionné, les résultats ne sont pas affichés tant que chacun des emplacements fédérés n’a pas retourné les résultats ou dépassé le délai imparti. Le délai d’expiration est défini sur 90 secondes et ne peut pas être modifié.

Un aspect important à évaluer lors de l’utilisation de la recherche fédérée est le découpage des résultats de recherche à des fins de sécurité. Par défaut, la fonction de découpage des résultats de recherche à des fins de sécurité persiste pour les résultats retournés par :

• les emplacements d’index de recherche locale (batterie de serveurs locale) ;

• les emplacements OpenSearch qui utilisent des informations d’identification communes (ensemble unique d’informations d’identification pour tous les utilisateurs) ;

• les emplacements OpenSearch qui utilisent l’authentification Kerberos par utilisateur.

Toutefois, les informations d’identification utilisateur ne sont pas transmises automatiquement dans le cas des protocoles d’authentification autres que Kerberos. Pour que les résultats soient découpés à des fins de sécurité pour l’utilisateur actuel dans ces scénarios, étendez le composant WebPart de résultats fédérés de manière à collecter les informations d’identification utilisateur. Pour plus d’informations, voir Création d’un composant WebPart de recherche fédérée personnalisé avec une interface utilisateur d’informations d’identification (en anglais) (https://go.microsoft.com/fwlink/?linkid=121779&clcid=0x40C) (en anglais).

Envisagez également d’utiliser le composant WebPart de résultats fédérés supérieurs qui affiche les résultats supérieurs à partir de plusieurs emplacements fédérés. Toutefois, ce composant est configuré pour afficher les résultats de façon synchrone et ce paramètre ne peut pas être modifié. Par conséquent, la durée de chargement des pages est aussi rapide que l’emplacement le plus lent configuré dans votre composant WebPart de résultats fédérés supérieurs. Si l’authentification Kerberos n’est pas utilisée, vous devrez également étendre ce composant WebPart pour collecter les informations d’identification utilisateur si vous souhaitez que les résultats de recherche pour les emplacements OpenSearch (tous les emplacements distants autres que la batterie de serveurs locale) soient découpés à des fins de sécurité pour chaque utilisateur.

Enfin, bien que la recherche fédérée permette aux utilisateurs d’obtenir des résultats issus de plusieurs sources de recherche, les utilisateurs ne bénéficient que des options de recherche standard. Les options de recherche avancées ne peuvent pas être utilisées avec la recherche fédérée.

Utilisation de la recherche fédérée avec des batteries de serveurs exécutant Windows SharePoint Services

Pour utiliser la recherche fédérée avec une batterie de serveurs exécutant Windows SharePoint Services, mettez à niveau la batterie de serveurs exécutant Windows SharePoint Services vers Search Server 2008 Express ou Search Server 2008. La mise à niveau permet de bénéficier d’une recherche au niveau de la batterie de serveurs exécutant Windows SharePoint Services au lieu d’une recherche limitée uniquement à chaque base de données de contenu. En outre, Serveur de recherche est requis pour la diffusion des flux RSS sur les résultats. RSS permet de créer un emplacement OpenSearch fédéré pour les résultats d’une batterie de serveurs distante afin que les résultats s’affichent sur la page unifiée.

Le schéma suivant illustre un environnement distribué géographiquement comportant des batteries de serveurs exécutant Windows SharePoint Services mises à niveau vers Search Server 2008 aux emplacements régionaux.

Résumé de la recherche fédérée

L’utilisation de la recherche fédérée présente de nombreux avantages dans un déploiement géographique. La recherche fédérée élimine la nécessité d’analyser ou de synchroniser du contenu sur des connexions WAN. L’affichage des résultats dans différents composants WebPart permet aux utilisateurs de déterminer l’emplacement du contenu, ce qui facilite l’identification du contenu local. En outre, le fait de comprendre où se trouve le contenu peut aider un utilisateur à déterminer les résultats potentiellement les plus pertinents.

Toutefois, cette architecture présente quelques inconvénients. Tout d’abord, la pertinence des résultats de la recherche ne peut pas être assurée à l’échelle de l’entreprise, mais elle est limitée à chaque emplacement fédéré. Ensuite, les performances des requêtes pour les emplacements distants sont tributaires des liaisons WAN. Cependant, les utilisateurs reçoivent généralement les résultats de recherche pour la batterie de serveurs locale assez rapidement.

Le tableau ci-dessous récapitule les avantages et les inconvénients de l’architecture de recherche fédérée.

Avantages

Inconvénients

Fournit une recherche à l’échelle de l’entreprise. Aucune limite au nombre de documents ou d’éléments pouvant être exclus de la recherche. Le contenu n’est pas analysé ou synchronisé sur des liaisons WAN. Les performances des requêtes sont optimisées pour le contenu local tandis que des résultats sont parallèlement fournis pour le contenu distant. Les utilisateurs peuvent effectuer des recherches dans différents emplacements sans se connecter à chacun d’eux. Chaque magasin de contenu peut être géré séparément. Windows SharePoint Services avec Search Server 2008 peut être utilisé sur des batteries de serveurs régionales, au lieu d’Office SharePoint Server. Le découpage à des fins de sécurité est conservé pour la batterie de serveurs locale et pour les batteries de serveurs distantes si l’authentification Kerberos est utilisée.

La pertinence de la recherche n’est pas assurée à l’échelle de l’entreprise. La pertinence est limitée à chaque source de contenu. La gestion de plusieurs fournisseurs de services partagés ou déploiements de Search Server 2008 augmente les coûts d’administration. Les performances des requêtes pour les emplacements distants sont tributaires des liaisons WAN. Le contenu n’étant pas synchronisé dans l’environnement, les utilisateurs téléchargent des documents sur des liaisons WAN pendant les heures de pointe pour l’utilisation de la bande passante. Les utilisateurs ne peuvent pas utiliser des options de recherche avancées. Si l’authentification Kerberos n’est pas utilisée, la conservation de la fonction de découpage des résultats de recherche à des fins de sécurité nécessite l’extension des composants WebPart de recherche fédérée.

Télécharger ce livre

Cette rubrique est incluse dans le livre à télécharger suivant pour une lecture et une impression plus faciles :

• Planification et architecture d’Office SharePoint Server 2007, partie 2

Vous trouverez la liste complète des livres disponibles sur Livres à télécharger pour Office SharePoint Server 2007.

Voir aussi

Concepts

Solutions globales prises en charge pour Office SharePoint Server
Concevoir l’architecture globale des informations et le plan de gouvernance
Planifier la configuration requise pour la bande passante