Planifier la disponibilité (SharePoint Server 2010)
S’applique à : SharePoint Foundation 2010, SharePoint Server 2010
Dernière rubrique modifiée : 2016-11-30
Cet article décrit les principales décisions en termes de choix des stratégies de disponibilité pour un environnement Microsoft SharePoint Server 2010.
Au moment d’évaluer précisément vos besoins en matière de disponibilité, gardez à l’esprit que plus le niveau de disponibilité et le nombre de systèmes à protéger sont élevés, plus votre solution de disponibilité est susceptible d’être complexe et onéreuse.
Dans une organisation, toutes les solutions ne requièrent pas nécessairement le même niveau de disponibilité. Vous pouvez offrir différents niveaux de disponibilité pour différents sites, différents services ou différentes batteries de serveurs.
Dans cet article :
Vue d’ensemble de la disponibilité
Choix d’une stratégie et d’un niveau de disponibilité
Redondance et basculement entre des centres de données très proches configurés en tant que batterie de serveurs unique (batterie de serveurs étirée)
Vue d’ensemble de la disponibilité
La disponibilité est le niveau auquel un environnement SharePoint Server est perçu par les utilisateurs comme étant disponible. Un système disponible est un système robuste ; en d’autres termes, les incidents qui affectent le service se produisent peu fréquemment et donnent lieu à une action rapide et efficace.
La disponibilité est une composante de la gestion de la continuité des opérations et est liée à la sauvegarde et à la récupération, ainsi qu’à la récupération d’urgence. Pour plus d’informations sur ces processus connexes, voir Planifier la sauvegarde et la récupération dans SharePoint Server 2010 et Planification de la récupération d’urgence (SharePoint Server 2010).
Notes
Lors du calcul de la disponibilité, la plupart des entreprises ajoutent ou retirent des heures pour les activités de maintenance planifiées.
L’une des mesures les plus courantes de la disponibilité est le pourcentage de temps de fonctionnement exprimé sous forme d’une série de neufs, c’est-à-dire le pourcentage de temps pendant lequel un système donné est actif et fonctionne. Par exemple, un système avec un pourcentage de temps de fonctionnement de 99,999 correspond à une disponibilité de cinq neufs.
Le tableau suivant établit une correspondance entre le pourcentage de temps de fonctionnement et les périodes calendaires.
| Pourcentage de temps de fonctionnement acceptable | Temps mort par jour | Temps mort par mois | Temps mort par an |
|---|---|---|---|
95 |
72,00 minutes |
36 heures |
18,26 jours |
99 (deux neufs) |
14,40 minutes |
7 heures |
3,65 jours |
99,9 (trois neufs) |
86,40 secondes |
43 minutes |
8,77 heures |
99,99 (quatre neufs) |
8,64 secondes |
4 minutes |
52,60 minutes |
99,999 (cinq neufs) |
0,86 secondes |
26 secondes |
5,26 minutes |
Si vous pouvez évaluer objectivement le nombre total d’heures de temps mort pouvant se produire par an, vous pouvez utiliser les formules suivantes pour calculer le pourcentage de temps de fonctionnement pour une année, un mois ou une semaine :
% temps de fonctionnement/an = 100 - (8 760 - nombre total d’heures de temps mort par an)/8 760
% temps de fonctionnement/mois = 100 - ((24 × nombre de jours dans le mois) - nombre total d’heures de temps mort dans ce mois calendaire)/(24 × nombre de jours dans le mois)
% temps de fonctionnement/semaine = 100 - (168 - nombre total d’heures de temps mort dans cette semaine)/168
Coûts de la disponibilité
La disponibilité est l’une des exigences les plus coûteuses pour un système. Plus le niveau de disponibilité est élevé et plus il y a de systèmes à protéger, plus la solution de disponibilité est susceptible d’être complexe et onéreuse. Lorsque vous investissez en disponibilité, les facteurs de coûts sont les suivants :
Matériels et logiciels supplémentaires, ce qui peut accroître la complexité des interactions entre les applications et les paramètres.
Complexité opérationnelle supplémentaire.
Les coûts d’amélioration de la disponibilité doivent être évalués conjointement avec les besoins de votre entreprise : dans une organisation, toutes les solutions ne requièrent pas nécessairement le même niveau de disponibilité. Vous pouvez offrir différents niveaux de disponibilité pour différents sites, différents services ou différentes batteries de serveurs.
La disponibilité est un domaine essentiel dans lequel les groupes informatiques proposent des contrats de niveau de service pour définir les attentes avec les groupes de clients. De nombreuses organisations informatiques offrent différents contrats de niveau de service associés à différents niveaux de facturation.
Détermination des besoins en matière de disponibilité
Pour évaluer la tolérance de temps mort de votre organisation pour un site, un service ou une batterie de serveurs, répondez aux questions suivantes :
En cas d’indisponibilité du site, du service ou de la batterie de serveurs, les employés sont-ils dans l’impossibilité de remplir leurs tâches ?
En cas d’indisponibilité du site, du service ou de la batterie de serveurs, les opérations commerciales et avec les clients sont-elles interrompues, avec à la clé une perte de chiffre d’affaires et de clients ?
Si vous avez répondu « Oui » à l’une de ces questions, vous devez investir dans une solution de disponibilité.
Choix d’une stratégie et d’un niveau de disponibilité
Vous pouvez choisir parmi plusieurs approches pour améliorer la disponibilité dans un environnement SharePoint Server notamment les suivantes :
améliorer la tolérance de panne des composants matériels de serveur ;
accroître la redondance des rôles de serveur dans une batterie de serveurs.
Tolérance de panne des composants matériels
La tolérance de panne des composants matériels désigne la redondance des composants matériels et des systèmes d’infrastructure tels que les blocs d’alimentation au niveau du serveur. Lorsque vous planifiez la tolérance de panne des composants matériels, prenez en considération les éléments suivants :
Une redondance complète de chaque composant au sein d’un serveur peut s’avérer impossible ou peu pratique. Utilisez des serveurs supplémentaires pour accroître la redondance.
Vérifiez que les serveurs disposent de plusieurs blocs d’alimentation connectés à différentes sources d’alimentation pour une redondance maximale.
Pour tout système, il est recommandé de collaborer avec les fournisseurs de matériel afin d’obtenir une configuration matérielle à tolérance de panne appropriée, y compris des dispositifs RAID (Redundant Array of Independent Disks). Pour des recommandations, voir Gestion de la performance et de la capacité (SharePoint Server 2010) et Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server 2010).
Redondance dans une batterie de serveurs
SharePoint Server 2010 prend en charge l’exécution de rôles de serveur sur des ordinateurs redondants (montée en puissance parallèle) au sein d’une batterie de serveurs pour accroître la capacité et fournir une disponibilité de base.
La capacité dont vous avez besoin détermine le nombre et la taille des serveurs de la batterie de serveurs. Une fois les exigences de capacité de base satisfaites, vous pouvez ajouter des serveurs pour accroître la disponibilité globale. L’illustration suivante montre comment vous pouvez instaurer une redondance pour chaque rôle de serveur.
Disponibilité au sein d’une batterie de serveurs
.gif "Disponibilité d’une batterie de serveurs unique")
Le tableau suivant décrit les rôles de serveur dans un environnement SharePoint Server 2010 et les stratégies de redondance pouvant être utilisées pour chacun dans une batterie de serveurs.
| Rôle de serveur | Stratégie de redondance par défaut dans une batterie de serveurs |
|---|---|
Serveur Web frontal |
Déployer plusieurs serveurs Web frontaux dans une batterie de serveurs et utiliser l’équilibrage de la charge réseau. |
Serveur d’applications |
Déployer plusieurs serveurs d’applications au sein d’une batterie de serveurs. |
Serveur de base de données |
Déployer des serveurs de base de données en utilisant le clustering ou la mise en miroir de bases de données à haut niveau de disponibilité. |
Stratégies de disponibilité des bases de données
Vous pouvez utiliser le clustering avec basculement Microsoft SQL Server ou la mise en miroir de bases de données à haut niveau de disponibilité SQL Server pour prendre en charge la disponibilité des bases de données dans un environnement SharePoint Server.
Clustering avec basculement SQL Server
Le clustering avec basculement peut assurer la prise en charge de la disponibilité pour une instance de SQL Server. Un cluster de basculement est la combinaison d’un ou plusieurs nœuds ou serveurs et de deux ou plusieurs disques partagés. Une instance de cluster de basculement se présente sous la forme d’un ordinateur unique, mais dispose de fonctionnalités qui assurent le basculement d’un nœud vers un autre si le nœud actuel devient indisponible. SharePoint Server peut s’exécuter sur n’importe quelle combinaison de nœuds actifs et passifs dans un cluster pris en charge par SQL Server.
SharePoint Server référence le cluster dans son ensemble ; par conséquent, le basculement est automatique et transparent du point de vue de SharePoint Server.
Pour des informations détaillées sur le clustering avec basculement, voir Mise en route avec le clustering avec basculement de SQL Server 2008 R2 (https://go.microsoft.com/fwlink/?linkid=102837&clcid=0x40C) et Configurer la disponibilité à l’aide du clustering SQL Server (SharePoint Server 2010).
Mise en miroir à haut niveau de disponibilité SQL Server
La mise en miroir de bases de données est une technologie SQL Server qui peut fournir une redondance spécifique pour chaque de base de données. Dans la mise en miroir de bases de données, les transactions sont envoyées directement depuis une base de données et un serveur principaux à une base de données et un serveur miroirs lorsque la mémoire tampon du journal des transactions de la base de données principale est écrite sur le disque. Grâce à cette technique, la base de données miroir est pratiquement synchronisée avec la base de données principale. SQL Server Enterprise Edition fournit des fonctionnalités supplémentaires qui améliorent les performances de la mise en miroir de bases de données. Pour plus d’informations, voir SQL Server 2008 R2 et les produits SharePoint 2010 : une association efficace (livre blanc) (SharePoint Server 2010).
Dans le cas d’une batterie de serveurs SharePoint Server, vous devez utiliser une mise en miroir à haut niveau de disponibilité, également appelée mode haute sécurité avec basculement automatique. La mise en miroir de bases de données à haut niveau de disponibilité implique trois instances de serveur : un serveur principal, un serveur miroir et un serveur témoin. Le serveur témoin permet à SQL Server de basculer automatiquement depuis le serveur principal vers le serveur miroir. En règle générale, le basculement depuis la base de données principale vers la base de données miroir prend plusieurs secondes.
Par rapport aux versions précédentes, SharePoint Server est compatible avec la mise en miroir. Après avoir configuré une instance de miroir de base de données de SQL Server, vous utilisez l’Administration centrale de SharePoint ou des applets de commande Windows PowerShell pour identifier l’emplacement du serveur de base de données de basculement (miroir) pour une base de données de configuration, une base de données de contenu ou une base de données d’application de service. La définition d’un emplacement de base de données de basculement ajoute un paramètre à la chaîne de connexion que SharePoint Server utilise pour se connecter à SQL Server. En cas d’événement de délai d’expiration SQL Server, les opérations suivantes se produisent :
Le serveur témoin configuré pour la mise en miroir SQL Server permute automatiquement les rôles des bases de données principale et miroir.
SharePoint Server essaie de contacter automatiquement le serveur spécifié comme base de données de basculement.
Pour plus d’informations sur la configuration de la mise en miroir de bases de données, voir Configurer la disponibilité à l’aide de la mise en miroir de bases de données SQL Server (SharePoint Server 2010).
Pour des informations générales sur la mise en miroir de bases de données, voir Mise en miroir de bases de données (https://go.microsoft.com/fwlink/?linkid=180597&clcid=0x40C).
Notes
Les bases de données configurées de manière à utiliser le fournisseur de magasins d’objets blob distants FILESTREAM SQL Server ne peuvent pas être mises en miroir.
Comparaison des stratégies de disponibilité des bases de données pour une batterie de serveurs unique : clustering avec basculement SQL Server et mise en miroir à haut niveau de disponibilité SQL Server
Le tableau suivant compare le clustering avec basculement et la mise en miroir à haut niveau de disponibilité SQL Server synchrone.
| Clustering avec basculement SQL Server | Mise en miroir à haut niveau de disponibilité SQL Server | |
|---|---|---|
Délai de basculement |
Le membre du cluster prend le relais immédiatement après l’échec. |
Le miroir prend le relais immédiatement après l’échec. |
Cohérence transactionnelle ? |
Oui |
Oui |
Simultanéité transactionnelle ? |
Oui |
Oui |
Délai de récupération |
Court délai de récupération (millisecondes) |
Délai de récupération légèrement supérieur (millisecondes). |
Étapes nécessaires pour le basculement ? |
L’échec est automatiquement détecté par les nœuds de base de données ; étant donné que SharePoint Server 2010 référence le cluster, le basculement est transparent et automatique. |
L’échec est automatiquement détecté par la base de données ; étant donné que SharePoint Server 2010 connaît l’emplacement du miroir s’il a été configuré correctement, le basculement est automatique. |
Protection contre un échec de stockage ? |
Ne protège pas contre un échec de stockage, car le stockage est partagé entre les nœuds du cluster. |
Protège contre un échec de stockage, car les serveurs de base de données principal et miroir effectuent des opérations d’écriture sur les disques locaux. |
Types de stockage pris en charge |
Stockage partagé (plus onéreux). |
Peut utiliser un stockage à connexion directe moins onéreux. |
Exigences en matière d’emplacement |
Les membres du cluster doivent appartenir au même sous-réseau. |
Les serveurs principal, miroir et témoin doivent appartenir au même LAN (boucle de latence maximale de 1 milliseconde). |
Mode de récupération |
Le mode de récupération SQL Server complet est recommandé. Vous pouvez utiliser le mode de récupération simple SQL Server, mais le seul point de récupération disponible si le cluster est perdu est la dernière sauvegarde complète. Pour plus d’informations, voir Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server 2010) et Plan for SQL Server, storage and BLOB configuration (SharePoint Foundation 2010). |
Requiert le mode de récupération complet SQL Server. |
Incidence sur les performances |
Une certaine diminution des performances peut se produire pendant un basculement. |
La mise en miroir à haut niveau de disponibilité introduit une latence transactionnelle, car elle est synchrone. En outre, la mémoire et le processeur sont davantage sollicités. |
Charge opérationnelle |
Configuré et géré au niveau du serveur. |
La charge opérationnelle est supérieure au clustering. Doit être configuré et géré pour toutes les bases de données. La reconfiguration après le basculement est manuelle. |
Stratégies de redondance pour les applications de services
La stratégie de redondance que vous suivez pour protéger une application de service exécutée dans une batterie de serveurs varie selon l’emplacement dans lequel l’application de service stocke des données.
Applications de services qui stockent des données en dehors d’une base de données
Pour protéger une application de services qui stocke des données en dehors d’une base de données, installez l’application de service sur plusieurs serveurs d’applications afin d’instaurer une redondance au sein de l’environnement.
Dans cette version de SharePoint Server, lorsque vous installez une application de service sur plusieurs serveurs d’applications, les travaux du minuteur s’exécutent sur tous les serveurs d’applications qui exécutent l’instance de service associée à cette application de service ou sur le premier serveur disponible. Si un serveur d’applications échoue, les travaux du minuteur qui s’exécutent sur ce serveur sont redémarrés sur un autre serveur au moment où le travail du minuteur suivant est programmé pour s’exécuter.
L’installation d’une application de service sur plusieurs serveurs d’applications permet à celle-ci de s’exécuter de façon continue, mais n’offre pas de garantie contre les pertes de données. Si un serveur d’applications échoue, les connexions actives pour celui-ci sont perdues et les utilisateurs perdent certaines données.
Les applications de services suivantes stockent des données en dehors d’une base de données :
Access Services
Application Excel Services
Applications de services qui stockent des données dans des bases de données
Pour faciliter la protection des applications de services qui stockent des données dans des bases de données, vous devez suivre les étapes ci-après :
Installez le service sur plusieurs serveurs d’applications afin d’instaurer une redondance au sein de l’environnement.
Configurez le clustering ou la mise en miroir SQL Server pour protéger les données.
Les applications de services suivantes stockent des données dans des bases de données :
Application de service de recherche, notamment les bases de données suivantes :
Administration de la recherche
Analyse
Propriété
Notes
La mise en miroir des bases de données de recherche est prise en charge, mais l’instauration d’une redondance pour la recherche requiert un travail supplémentaire. Pour plus d’informations, voir la section Stratégies de redondance pour la recherche au sein d’une batterie de serveurs.
Service de profil utilisateur, notamment les bases de données suivantes :
Profils
Sociale
Synchronisation
Notes
La mise en miroir de la base de données de synchronisation n’est pas prise en charge.
Application du Service Business Data Connectivity
Application de service de registre d’application
Il n’est pas recommandé de mettre en miroir la base de données de registre d’application, car elle est uniquement utilisée lors de la mise à niveau des informations du catalogue de données métiers Microsoft Office SharePoint Server 2007 vers SharePoint Server 2010.
Application de service de collecte de données relatives à l’état et à l’utilisation
Notes
Il est recommandé de ne pas mettre en miroir la base de données de journalisation de l’application de service de collecte de données relatives à l’état et à l’utilisation.
Application de service de métadonnées gérées
Application du service Banque d’informations sécurisé
Application de service d’états temporaires
Application de service Web Analytics, notamment les bases de données suivantes :
Création de rapports
Zone de transit
Notes
La mise en miroir de la base de données de la zone de transit n’est pas prise en charge.
Application de service Word Automation Services
Service de paramètres d’abonnement Microsoft SharePoint Foundation
PerformancePoint Services
Stratégies de redondance pour la recherche au sein d’une batterie de serveurs
Serveur uniquement
L’application de service de recherche constitue un cas spécial pour la redondance dans une batterie de serveurs. L’illustration suivante montre comment la redondance et le basculement peuvent être configurés pour une application de service de recherche dédiée de taille moyenne qui analyse approximativement 40 millions d’éléments. Pour plus d’informations sur l’architecture de l’application de service de recherche, voir « Architectures de recherche pour Microsoft SharePoint Server 2010 » dans l’article Diagrammes techniques (SharePoint Server 2010).
Application de service de recherche redondante
.gif "Architecture de recherche à haute disponibilité")
Serveur de requête. Un serveur de requête héberge des composants de requête et des partitions d’index.
Les composants de requête retournent des résultats de recherche. Chaque composant de requête fait partie d’une partition d’index, qui est associée à une base de données de propriétés spécifique contenant les métadonnées liées à un ensemble spécifique de contenu analysé. Vous pouvez rendre une partition d’index redondante en y ajoutant des composants de requête « miroirs » et en les plaçant sur différents serveurs de la batterie de serveurs.
Notes
L’utilisation du terme composants de requête miroirs fait référence à des copies de fichier identiques et ne désigne pas une mise en miroir de bases de données SQL Server.
Les partitions d’index sont des groupes de composants de requête, dont chacune contient un sous-ensemble de l’index de texte intégral et retourne des résultats de recherche. Chaque partition d’index est associée à une base de données de propriétés spécifique contenant les métadonnées associées à un ensemble précis de contenu analysé. Vous pouvez choisir les serveurs de la batterie de serveurs qui traiteront les requêtes en créant un composant de requête sur ce serveur. Si vous souhaitez équilibrer la charge de traitement de requêtes entre plusieurs serveurs de la batterie, ajoutez des composants de requête à une partition d’index et associez-les aux serveurs à utiliser pour le traitement des requêtes. Pour plus d’informations, voir Ajouter ou supprimer un composant de requête. Vous pouvez rendre une partition d’index redondante en y ajoutant des composants de requête miroirs et en les plaçant sur différents serveurs de requête.
Serveur d’analyse. Un serveur d’analyse héberge des composants d’analyse et un composant d’administration de la recherche.
Les composants d’analyse traitent les analyses de sources de contenu, propagent les fichiers d’index obtenus aux composants de requête et ajoutent des informations sur l’emplacement et la planification d’analyse des sources de contenu à leurs bases de données d’analyse associée. Les composants d’analyse sont associés à une application de service de recherche unique. Vous pouvez répartir la charge de l’analyse en ajoutant des composants d’analyse à différents serveurs d’analyse. Vous pouvez placer sur un serveur d’analyse donné autant de composants d’analyse que les ressources vous le permettent. Si vous disposez de plusieurs emplacements de contenu, vous pouvez ajouter des composants d’analyse et des bases de données d’analyse, puis les dédier à du contenu spécifique. Chaque composant d’analyse sur un serveur d’analyse donné doit être associé à une base de données d’analyse distincte. Pour assurer une redondance, il est recommandé de disposer de deux composants d’analyse au moins. Chaque composant d’analyse doit être configuré de manière à analyser les deux bases de données d’analyse. Si une base de données dépasse la barre de 25 millions d’éléments, il est recommandé d’ajouter une nouvelle base de données d’analyse et un nouveau composant d’analyse.
Le composant d’administration de la recherche surveille les actions utilisateur entrantes et met à jour la base de données d’administration de la recherche. Un seul composant d’administration de la recherche est autorisé par application de service de recherche. Le composant d’administration de la recherche peut s’exécuter sur n’importe quel serveur, de préférence sur un serveur d’analyse ou sur un serveur de requête.
Serveurs de base de données. Les serveurs de base de données hébergent les bases de données d’analyse, les bases de données de propriétés, la base de données d’administration de la recherche et d’autres bases de données SharePoint Server 2010.
Base de données d’analyse
Les bases de données d’analyse contiennent des données relatives à l’emplacement des sources de contenu, aux planifications d’analyse, ainsi que d’autres informations propres aux opérations d’analyse d’une application de service de recherche spécifique. Vous pouvez répartir la charge des bases de données en ajoutant des bases de données d’analyse à différents ordinateurs exécutant SQL Server. Les bases de données d’analyse sont associées aux composants d’analyse et vous pouvez les dédier à des hôtes spécifiques en créant des règles de distribution des hôtes. Pour plus d’informations sur les composants d’analyse, voir Ajouter ou supprimer un composant d’analyse. Pour plus d’informations sur les règles de distribution des hôtes, voir Ajouter ou supprimer une règle de distribution d’hôte. Les bases de données d’analyse sont redondantes si elles sont mises en miroir ou déployées sur un cluster de basculement SQL Server.
Base de données de propriétés
Les bases de données de propriétés contiennent des métadonnées associées au contenu analysé. Vous pouvez distribuer la charge de la base de données de requêtes en ajoutant des bases de données de propriétés à différents ordinateurs qui exécutent SQL Server. Les bases de données de propriétés sont associées aux partitions d’index et renvoient les métadonnées associées au contenu dans les résultats de requête.
Les bases de données de propriétés sont redondantes si elles sont mises en miroir ou déployées sur un cluster de basculement SQL Server.
Base de données d’administration de la recherche
Il existe une seule base de données d’administration de la recherche par instance d’application de service de recherche dans une batterie de serveurs.
La base de données d’administration de la recherche est uniquement redondante si elle est mise en miroir ou déployée sur un cluster de basculement SQL Server.
Pour plus d’informations sur la redondance pour la recherche, voir Gérer la topologie de recherche.
Redondance et basculement entre des centres de données très proches configurés en tant que batterie de serveurs unique (batterie de serveurs étirée)
Certaines entreprises possèdent des centres de données proches les uns des autres et reliés par des connexions à large bande passante, ce qui permet de les configurer en tant que batterie de serveurs unique, dénommée alors batterie de serveurs étirée. Une batterie de serveurs étirée ne fonctionne que si la latence entre SQL Server et les serveurs Web frontaux est inférieure à 1 milliseconde dans un sens et que la bande passante s’élève à au moins 1 gigabit par seconde.
Dans ce scénario, vous pouvez instaurer une tolérance de panne en suivant les conseils standard pour rendre des bases de données et des applications de services redondantes.
L’illustration suivante montre une batterie de serveurs étirée.
Batterie de serveurs étirée
.gif "Batterie de serveurs « étirée »")