Planifier la redondance (Search Server 2008)

Mise à jour : 2008-07-31

Dans cet article :

• À propos de la redondance

• Définition des besoins de redondance des serveurs

• Planification d'un niveau minimal de redondance des serveurs

• Choix d'une topologie de batterie de serveurs standard

• Planification de la redondance des serveurs de requête

• Planification de la redondance des serveurs de bases de données

• Évaluation des risques de pannes des serveurs

Cet article décrit les options d'évolution des rôles de serveurs redondants d'une batterie de serveurs Microsoft Search Server 2008. Après avoir lu cet article, vous serez à même de déterminer et d'enregistrer les options de redondance adaptées à votre environnement.

Avant de prendre connaissance de cette rubrique, lisez d'abord les rubriques suivantes :

• Planification du déploiement de Search Server 2008 ou de Search Server 2008 Express

• Déterminer la configuration matérielle et logicielle requise (Search Server 2008)

• Planifier la disponibilité (Search Server 2008)

Notez qu'en principe Search Server 2008 et Search Server 2008 Express n'hébergent pas de contenu. En effet, ils sont essentiellement utilisés pour héberger des services de recherche (Search), analyser du contenu sur des batteries Windows SharePoint Services et Microsoft Office SharePoint Server ou autres sources de contenu distantes, et pour répondre aux requêtes. Dans certains environnements, Search Server 2008 et Search Server 2008 Express peuvent servir à l'hébergement de contenu. Si vous envisagez d'utiliser Search Server 2008 ou Search Server 2008 Express pour héberger du contenu, listez les articles dans Planifier les performances et la capacité (Windows SharePoint Services) afin de vous assurer que vous comprenez bien les besoins en matière d'hébergement de contenu et d'exécution de Search Server 2008 ou de Search Server 2008 Express dans la même batterie de serveurs.

À propos de la redondance

Le terme redondanceest souvent mal interprété et confondu avec la disponibilité. Bien que ces concepts soient proches, ils ne sont pas identiques. La redondance fait référence à l'utilisation de plusieurs serveurs dans un environnement où la charge est équilibrée dans plusieurs buts (par exemple, amélioration des performances) de façon à évoluer pour accueillir des utilisateurs supplémentaires et à améliorer la disponibilité.

La disponibilité est un concept plus spécialisé, qui fait référence à un environnement multiserveur conçu pour accepter des connexions et fonctionner normalement lorsqu'un ou plusieurs serveurs de la batterie sont hors service. La disponibilité implique donc la redondance ainsi qu'un mécanisme de reprise après incident et éventuellement d'autres caractéristiques. Cependant, un système redondant n'offre peut-être pas une disponibilité élevée.

Pour plus d’informations sur la disponibilité, reportez-vous à la section Planifier la disponibilité (Search Server 2008).

Cet article explique comment implémenter des serveurs redondants dans une batterie de serveurs Search Server 2008.

Définition des besoins de redondance des serveurs

Search Server 2008 prend en charge les batteries de serveurs évolutives afin d’offrir capacité, performances et disponibilité. En général, la capacité est le premier point à considérer lors de la détermination du nombre d’ordinateurs serveurs initial. Une fois les performances analysées, la disponibilité joue également un rôle dans la détermination du nombre de serveurs et de la taille ou de la capacité des ordinateurs serveurs dans une batterie de serveurs.

À la fin de cette section, vous serez en mesure de déterminer si vous devez intégrer une capacité évolutive dans votre topologie de déploiement de serveurs en déployant des serveurs redondants, ou s'il est logique pour votre organisation de planifier un déploiement de serveurs limité qui ne comporte pas de serveurs redondants.

Planification d'un niveau minimal de redondance des serveurs

Pour déployer une solution redondante, vous devez déployer une batterie de serveurs.

Il existe plusieurs topologies de serveur qui peuvent être utilisées comme base. Chacune de ces topologies génère un niveau de redondance de serveur. Cette section passe en revue ces batteries de serveurs.

Remarque :
Dans les descriptions suivantes, les serveurs sur lesquels le rôle d’index a été installé sont désignés par le terme « serveurs d’index », tandis que les serveurs sur lesquels le rôle Requête a été installé sont désignés par le terme « serveurs de requête ».

Topologies redondantes

Cette section contient des exemples de topologies redondantes.

Batterie de cinq serveurs ou plus

La topologie de batterie de serveurs redondante optimale introduit un serveur d'index distinct et se compose de cinq serveurs au minimum, notamment deux serveurs de base de données en configuration cluster et au moins deux autres serveurs de requête.

Dans le cadre de cette topologie, vous pouvez installer le rôle de serveur d’index sur le serveur d’applications dédié. Cette conception optimise les performances des serveurs de requête en vous permettant de confier l'indexation au niveau intermédiaire.

Notez que cette topologie indique une configuration de clustering SQL Server qui assure un basculement manuel. Pour plus d'informations sur la façon de configurer un cluster SQL Server pour le basculement automatique, consultez Livre blanc de cluster de basculement SQL Server 2005 (en anglais) ou Installination d'un cluster de basculement SQL Server 2008, selon la version de SQL Server que vous utilisez.

Batterie à quatre serveurs

La plus petite batterie de serveurs qui crée la redondance se compose de quatre serveurs :

• Serveeurs 1 et 2 : rôle de requête installé sur les deux ordinateurs.

• Serveurs 3 et 4 : serveur de base de données en cluster ou mirroir.

Dans le cas d’une batterie composée de quatre serveurs, vous devez déterminer attentivement l’emplacement où déployer le rôle de serveur d’index. Vous ne pouvez pas assurer la redondance en déployant le rôle Requête à la fois sur le serveur d’index et sur un autre serveur de la batterie de serveurs. En effet, lorsque le rôle d’index est installé sur le même ordinateur serveur que le rôle Requête, le rôle d’index ne propage plus les index de contenu aux autres serveurs de requête. Par conséquent, si vous installez le rôle de serveur d’index sur l’un des serveurs Web, vous perdez la capacité à héberger le rôle Requête sur les deux serveurs Web. Vous pouvez installer le rôle d’index sur le serveur de base de données, assurant ainsi la redondance du rôle Requête sur les serveurs Web. Toutefois, les performances du serveur de base de données s’en ressentiront, notamment lors de l’analyse de contenu.

Batterie de trois serveurs

Il existe une autre solution pour assurer la redondance lorsque vous déployez un nombre inférieur de serveurs. Quand vous utilisez une batterie de trois serveurs, vous devez déterminer les rôles de serveurs à rendre redondants : le rôle de serveur Web ou celui de serveur de base de données.

En ajoutant un troisième serveur au niveau serveur Web, vous assurez la redondance du rôle de serveur Web. Les rôles de requête et d’index peuvent être installés sur le même serveur Web (voir l'option A dans cette section) ou sur des serveurs Web différents (voir l'option B dans cette section).

Cette topologie ne permet pas de déployer le rôle Requête sur les deux serveurs Web pour assurer la redondance. En effet, si le rôle de serveur de requête est installé sur le même serveur que le serveur d’index, celui-ci ne propage pas l’index aux autres serveurs de requête. Toutefois, vous pouvez installer le rôle d’index sur le serveur de bases de données. Vous pouvez ainsi déployer le rôle de requête sur les deux serveurs Web. Néanmoins, les performances du serveur de base de données s’en ressentiront.

Bien que la disponibilité soit limitée, le fait de dédier deux serveurs au rôle de serveur Web augmente les performances globales de la petite batterie. Utilisez cette topologie lorsque les performances sont plus importantes que la redondance des données.

Topologies non redondantes

Les topologies non redondantes peuvent contenir plusieurs serveurs, mais elles ne sont pas redondantes car il n'existe qu'un seul serveur par rôle de serveur. Par exemple, une batterie qui contient un seul serveur de requête, un seul serveur d'index et un seul serveur de base de données n'est pas redondante.

Si vous n'avez pas besoin de générer une capacité et des performances supplémentaires dans votre déploiement de serveurs, le point de départ pour votre topologie de serveurs est un ou deux serveurs. Pour une utilisation limité, vous pouvez déployer un seul serveur Search Server 2008 ou déployer Microsoft Search Server 2008 Express, qui est limité de par sa nature même aux serveurs d'applications uniques.

Les diagrammes suivants illustrent des exemples de topologies non redondantes.

Choix d'une topologie de batterie de serveurs standard

Chaque topologie de batterie de serveurs décrite précédemment dans cet article représente un point de départ initial pour la conception de votre déploiement. Le point de départ le mieux adapté à votre organisation dépend des rôles de serveurs pour lesquels il vous faut de la redondance.

Le reste de cet article décrit les options de redondance pour chacun des rôles de serveurs. Quand vous en aurez terminé avec cet article, vous serez à même de déterminer la topologie de base qui offre la redondance dont votre organisation a besoin. Il s'agit de votre topologie standard lorsque vous planifiez la capacité et les performances.

Planification de la redondance des serveurs de requête

Utilisez cette section pour :

• déterminer si l'organisation nécessite la redondance intégrée au niveau Web ;

• planifier le technologie d'équilibrage de charge de serveur de requête à mettre en œuvre.

Le rôle de serveur d’applications peut être déployé sur plusieurs serveurs. Le code qui est déployé sur chaque serveur est identique et les rôles de serveur d’applications ne stockent pas de données. En d’autres termes, chaque instance du rôle de serveur de requête reste identique. Si l’un des ordinateurs serveurs tombe en panne, aucune donnée enregistrée n’est perdue. Les serveurs de requête répartissent automatiquement la charge exercée sur les demandes adressées à ces rôles de serveur entre les ordinateurs serveurs disponibles.

Le rôle Requête peut être déployé sur un nombre quelconque de serveurs Web. Cependant, une limite est imposée. Si le rôle Requête est déployé sur le serveur qui héberge le rôle d’index, le rôle Requête ne doit pas être déployé sur tous les autres ordinateurs serveurs. Cela s'explique par le fait que le rôle d'index reconnaît que le rôle Requête est situé sur le même serveur. Par conséquent, il ne tente pas de propager l'index.

Le rôle de serveur d'applications d'index ne peut pas être redondant dans Search Server 2008. Dans Search Server 2008, le rôle d'index est associé un fournisseur de services partagés (SSP, Shared Services Provider). Le rôle d’index génère un index par SSP. Vous ne pouvez pas déployer plusieurs serveurs d’index afin d’améliorer la capacité. Le serveur d'index est associé à un seul SSP, et dans Search Server 2008, vous ne pouvez avoir qu'un seul SSP.

L'étape suivante consiste à planifier la technologie d'équilibrage de charge à mettre en œuvre. Search Server 2008 prend en charge deux méthodes d'équilibrage de charge :

• Une méthode logicielle, telle que les services d'équilibrage de la charge réseau NLBS dans le système d'exploitation Windows Server 2003. L'équilibrage de la charge réseau s'exécute sur les serveurs de requête et utilise le protocole TCP/IP pour acheminer les demandes. Dans la mesure où l’équilibrage de la charge réseau et d'autres solutions logicielles de ce type s’exécutent sur les serveurs de requête, ils utilisent les ressources système des serveurs de requête. Cela réduit les ressources pouvant être utilisées pour servir les requêtes. Toutefois, l'effet sur les ressources système n'est pas significatif, et une solution logicielle peut gérer jusqu'à 32 serveurs de requête.

• Une méthode matérielle, telle qu'un routeur ou commutateur. Le matériel d’équilibrage de charge utilise le réseau pour diriger le trafic de requête entre les serveurs de requête. Il est plus coûteux à configurer que les logiciels, mais il n’affecte pas l'utilisation des ressources sur les serveurs de requête. Search Server 2008 peut être utilisé avec n’importe quel matériel d’équilibrage de charge.

Bien qu'elle ne soit pas recommandée, il existe une troisième méthode d'équilibrage de charge, l'équilibrage de charge round robin avec DNS (Domain Name System). L'équilibrage de charge DNS round robin peut utiliser des ressources importantes sur les serveurs de requête, est plus lent que le matériel ou logiciel d'équilibrage de charge. Il n'est pas recommandé pour une utilisation avec Search Server 2008. En outre, l'équilibrage de charge DNS round robin ne prend pas en compte la charge de session lors du routage d'un utilisateur vers un serveur, ce qui peut entraîner la surcharge d'un serveur.

L'article Configurer les paramètres du service Équilibrage de la charge réseau dans Windows Server 2003 (https://go.microsoft.com/fwlink/?linkid=124067&clcid=0x40C) fournit des instructions pour configurer l'équilibrage de la charge réseau. Si vous choisissez d'implémenter une technologie différente pour l'équilibrage de charge, tenez-en compte dans le processus de planification et de déploiement.

Planification de la redondance des serveurs de bases de données

Utilisez cette section pour vous aider à déterminer si la redondance du rôle de serveur de base de données est requise pour la solution. Les rubriques suivantes de planification vous permettront de décider de la technologie de redondance de base de données la plus appropriée pour l’environnement. Pour plus d’informations, voir Planification et conception du stockage et de la gestion des bases de données.

Le rôle de serveur de base de données affecte la disponibilité de votre solution plus que n'importe quel autre rôle. Si un serveur de requête ou un serveur d'index échoue, ces rôles peuvent rapidement être restaurés ou redéployés. Toutefois, si un serveur de base de données échoue, votre solution dépend de la restauration du serveur de base de données. Cela peut éventuellement inclure la reconstruction du serveur de base de données, puis la restauration des données à partir de votre support de sauvegarde. Dans ce cas, vous pouvez potentiellement perdre les nouvelles données ou les données modifiées depuis la dernière tâche de sauvegarde, selon la façon dont SQL Server 2005 est configuré. En outre, la solution est complètement indisponible pendant le temps nécessaire à la restauration du rôle de serveur de bases de données.

Évaluation des risques de pannes des serveurs

Cette section résume les conséquences attendues d’une panne du serveur de requête ou du serveur d'index. En d’autres termes, si vous déployez un rôle de serveur de requête sur un seul serveur et que celui-ci tombe en panne, quelles sont les conséquences potentielles ? L’assimilation des conséquences potentielles vous permettra de hiérarchiser l’allocation des serveurs dans la batterie de serveurs. Le tableau suivant répertorie les rôles de serveur d’applications et décrit pour chacun les conséquences d’un temps d’arrêt.

En matière de redondance, la recommandation générale est de planifier l'installation du rôle de serveur de requête sur au moins deux ordinateurs serveurs si l'impératif de disponibilité pour le rôle de serveur de requête est au minimum de 99 pour cent.

Si votre organisation peut tolérer une perte temporaire de cette fonctionnalité pendant que l’équipe informatique déploie un rôle de serveur d’applications sur un autre serveur ou restaure le service sur le serveur existant, vous pouvez envisager de déployer le rôle sur un serveur d’applications unique.

Voir aussi

Planifier la disponibilité (Search Server 2008)

Autres ressources

Planification et conception du stockage et de la gestion des bases de données
COMMENT FAIRE : Configurer les paramètres du service Équilibrage de la charge réseau dans Windows Server 2003
Cluster de basculement SQL Server 2005 (Livre blanc)
Installation d'un cluster de basculement SQL Server 2008