Planifier la disponibilité (SharePoint Foundation 2010)
S’applique à : SharePoint Foundation 2010
Dernière rubrique modifiée : 2016-11-30
Cet article décrit les décisions fondamentales qui interviennent dans le choix de stratégies de disponibilité pour un environnement Microsoft SharePoint Foundation 2010.
Lorsque vous passez en revue vos besoins en matière de disponibilité, sachez que plus le niveau de disponibilité est élevé et plus le nombre de systèmes que vous devez protéger est important, plus la solution de disponibilité sera probablement complexe et coûteuse.
Toutes les solutions au sein d’une organisation n’exigent probablement pas le même niveau de disponibilité. Vous pouvez proposer différents niveaux de disponibilité pour différents sites, différents services ou différentes batteries.
Dans cet article :
Vue d’ensemble de la disponibilité
Choix d’une stratégie et d’un niveau de disponibilité
Redondance et basculement entre centres de données proches configurés comme batterie unique (batterie « étirée »)
Vue d’ensemble de la disponibilité
La disponibilité est le degré de perception de la disponibilité par les utilisateurs d’un environnement SharePoint Foundation. Un système disponible est un système résilient, c’est-à-dire que les incidents affectant le service se produisent rarement et qu’une action immédiate et efficace est effectuée lorsqu’ils se produisent.
La disponibilité fait partie de la gestion de la continuité des opérations ; elle est liée à la sauvegarde, à la récupération et à la récupération d’urgence. Pour plus d’informations sur ces processus associés, voir Planifier la sauvegarde et la récupération (SharePoint Foundation 2010) et Planifier la récupération d’urgence (SharePoint Foundation 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’un nombre de neufs : il s’agit du pourcentage de temps pendant lequel un système donné est en service et fonctionne. Par exemple, un système avec un pourcentage de temps de fonctionnement égal à 99,999 correspond à une disponibilité de cinq neufs.
Le tableau suivant met en corrélation les pourcentages de temps de fonctionnement et leur équivalent en durées calendaires.
| Pourcentage de temps d’activité acceptable | Temps d’immobilisation par jour | Temps d’immobilisation par mois | Temps d’immobilisation 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 établir une estimation censée du nombre total probable d’heures d’indisponibilité que vous pouvez rencontrer, vous pouvez utiliser les formules ci-dessous pour calculer le pourcentage de temps de fonctionnement par an, par mois et par semaine :
% temps de fonctionnement/an = 100 - (8760 - nombre total d’heures d’indisponibilité par an)/8760
% temps de fonctionnement/mois = 100 - ((24 × nombre de jours dans le mois) - nombre total d’heures d’indisponibilité dans ce mois)/(24 × nombre de jours dans le mois)
% temps de fonctionnement/semaine = 100 - (168 - nombre total d’heures d’indisponibilité dans cette semaine/168
Coûts de la disponibilité
La disponibilité est une des conditions les plus onéreuses d’un système. Plus le niveau de disponibilité est élevé et plus le nombre de systèmes que vous devez protéger est important, plus la solution de disponibilité sera probablement complexe et coûteuse. Lorsque vous investissez dans la disponibilité, les frais comprennent :
le matériel et les logiciels supplémentaires, impliquant souvent des opérations complexes entre les logiciels et les paramètres ;
la complexité opérationnelle supplémentaire.
Les coûts de la disponibilité doivent être évalués en fonction des besoins de votre entreprise : toutes les solutions au sein d’une organisation n’exigent probablement pas le même niveau de disponibilité. Vous pouvez proposer différents niveaux de disponibilité pour différents sites, différents services ou différentes batteries.
La disponibilité constitue un élément essentiel pour lequel les groupes informatiques proposent des contrats de niveau de service pour définir les attentes avec les groupes de clients. De nombreuses entreprises informatiques proposent divers contrats de niveau de service correspondant à différents niveaux de facturation.
Détermination des besoins en matière de disponibilité
Pour évaluer la tolérance de l’organisation sur les temps d’immobilisation d’un site, d’un service ou d’une batterie, répondez aux questions suivantes :
Si le site, le service ou la batterie n’est pas disponible, les employés de votre organisation seront-ils dans l’impossibilité d’exercer raisonnablement leurs fonctions ?
Si le site, le service ou la batterie n’est pas disponible, les transactions de l’entreprise et des clients seront-elles interrompues, entraînant une perte d’activité 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 l’une des approches permettant d’améliorer la disponibilité dans un environnement SharePoint Foundation, notamment :
améliorer la tolérance de panne des composants matériels du serveur ;
accroître la redondance des rôles de serveur d’une batterie ;
Tolérance de panne des composants matériels
La tolérance de panne des composants matériels est la redondance des composants matériels et des systèmes d’infrastructure, par exemple les alimentations au niveau du serveur. Lors de la planification de la tolérance de panne des composants matériels, tenez compte des points suivants :
La redondance totale de chaque composant d’un serveur n’est peut-être pas possible ou peut être difficile. Utilisez des serveurs supplémentaires pour une meilleure redondance.
Vérifiez que les serveurs sont équipés de plusieurs alimentations connectées à des sources différentes pour une redondance maximale.
Dans n’importe quel système, il est recommandé de travailler avec les fabricants de matériel pour bénéficier de la tolérance de panne adaptée au système, y compris des contrôleurs RAID (Redundant Array of Independent Disks).
Redondance dans une batterie
SharePoint Foundation 2010 prend en charge les rôles serveur en cours d’exécution sur des ordinateurs redondants (c’est-à-dire l’évolution) dans une batterie pour augmenter la capacité et procurer une disponibilité standard.
La capacité désirée détermine à la fois le nombre et la taille des serveurs d’une batterie. Lorsque les conditions de base sont remplies, vous voudrez peut-être ajouter des serveurs supplémentaires pour augmenter la disponibilité globale. L’illustration suivante montre comment assurer la redondance pour chaque rôle serveur.
Disponibilité dans une batterie de serveurs
.gif "Disponibilité d’une batterie de serveurs unique")
Le tableau ci-dessous décrit les serveurs et les rôles de serveur dans un environnement SharePoint Foundation 2010 et les stratégies de redondance standard utilisables pour chacun d’entre eux dans une batterie.
| Rôle serveur | Stratégie préférable de redondance dans une batterie |
|---|---|
Serveur Web frontal |
Déploiement de plusieurs serveurs Web frontaux dans une batterie et utilisation de l’équilibrage de la charge réseau |
Serveur d’applications |
Déploiement de plusieurs serveurs d’applications dans une batterie |
Serveur de bases de données |
Déploiement de serveurs de bases de données via clustering ou mise en miroir de bases de données à haute disponibilité |
Stratégies de disponibilité de base de données
Vous pouvez utiliser le clustering avec basculement Microsoft SQL Server ou la mise en miroir de bases de données à haute disponibilité SQL Server pour prendre en charge la disponibilité des bases de données dans un environnement SharePoint Foundation.
Clustering avec basculement SQL Server
Le clustering avec basculement peut assurer la disponibilité d’une instance de SQL Server. Un cluster de basculement est une combinaison d’un ou plusieurs nœuds ou serveurs et de deux disques partagés ou plus. Une instance de cluster de basculement apparaît comme un ordinateur unique, mais possède des fonctionnalités qui assure le basculement d’un nœud vers un autre si le nœud actuel devient indisponible. SharePoint Foundation peut exécuter n’importe quelle combinaison de nœuds actifs et passifs dans un cluster pris en charge par SQL Server.
SharePoint Foundation fait référence au cluster dans sa globalité ; par conséquent, le basculement est automatique et transparent du point de vue de SharePoint Foundation.
Pour des informations détaillées sur le clustering avec basculement, voir Mise en route avec le clustering avec basculement de SQL Server 2008 (https://go.microsoft.com/fwlink/?linkid=102837&clcid=0x40C) et Configurer la disponibilité à l’aide de la mise en cluster SQL Server (SharePoint Foundation 2010).
Mise en miroir à haute disponibilité SQL Server
La mise en miroir de base de données est une technologie SQL Server qui peut assurer la redondance de base de données, une base de données à la fois. Dans le cadre de la mise en miroir de base de données, des transactions sont envoyées directement d’une base de données principale sur un serveur principal à une base de données miroir sur un serveur miroir lorsque le tampon du journal des transactions de la base de données principale est écrit sur disque. Cette technique peut permettre d’obtenir une base de données miroir quasiment à jour avec la base de données principale. SQL Server Enterprise Edition fournit des fonctionnalités supplémentaires qui améliorent les performances de mise en miroir des bases de données.
Pour effectuer une mise en miroir dans une batterie SharePoint Foundation, vous devez utiliser une mise en miroir à haute disponibilité, aussi appelée « Haute sécurité avec basculement automatique ».La mise en miroir de base de données à haute 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 du serveur principal sur le serveur miroir. Le basculement de la base de données principale sur la base de données miroir prend généralement plusieurs secondes.
Contrairement aux versions précédentes, SharePoint Foundation prend en charge la mise en miroir. Après avoir configuré une instance de miroir de base de données de SQL Server, utilisez l’Administration centrale de SharePoint ou les applet de commande Windows PowerShell pour identifier l’emplacement du serveur de bases 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. Le fait de définir un emplacement de base de données de basculement ajoute un paramètre à la chaîne de connexion utilisée par SharePoint Foundation pour se connecter à SQL Server. En cas de délai d’attente SQL Server, les événements suivants se produisent :
Le serveur témoin qui est configuré pour la mise en miroir SQL Server échange automatiquement les rôles des bases de données primaire et miroir.
SharePoint Foundation tente automatiquement de contacter 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 base de données SQL Server (SharePoint Foundation 2010).
Pour obtenir 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 qui ont été configurées de manière à utiliser le fournisseur de magasin d’objets BLOB à distance FILESTREAM SQL Server ne peuvent pas être mises en miroir.
Comparaison des stratégies de disponibilité des bases de données pour une batterie unique : clustering avec basculement SQL Server et mise en miroir à haute disponibilité SQL Server
Le tableau ci-dessous compare le clustering avec basculement et la mise en miroir à haute disponibilité SQL Server synchrone.
| Clustering avec basculement SQL Server | Mise en miroir à haute disponibilité SQL Server | |
|---|---|---|
Temps de basculement |
Le membre du cluster entre immédiatement en service en cas de défaillance. |
Le miroir entre immédiatement en service en cas de défaillance. |
Cohérence des transactions ? |
Oui |
Oui |
Concurrence des transactions ? |
Oui |
Oui |
Temps de récupération |
Temps de récupération plus court (quelques millisecondes). |
Temps de récupération légèrement plus long (quelques millisecondes). |
Étapes requises pour le basculement ? |
La défaillance est automatiquement détectée par les nœuds de la base de données. SharePoint Foundation 2010 fait référence au cluster ; le basculement est donc transparent et automatique. |
La défaillance est automatiquement détectée par la base de données. SharePoint Foundation 2010 a connaissance de l’emplacement du miroir s’il a été configuré correctement ; le basculement est donc automatique. |
Protection contre les défaillances de stockage ? |
Ne protège pas contre les défaillances de stockage, car le stockage est partagé entre les nœuds du cluster. |
Protège contre les défaillances de stockage, car les serveurs des bases de données principale et miroir écrivent sur des disques locaux. |
Types de stockage pris en charge |
Stockage partagé (plus coûteux). |
Peut utiliser le stockage à connexion directe (DAS) moins coûteux. |
Besoins en termes d’emplacement |
Les membres du cluster doivent être sur le même sous-réseau. |
Les serveurs principal, miroir et témoin doivent être sur le même LAN (jusqu’à 1 ms de latence aller-retour). |
Modèle de récupération |
mode de récupération complète SQL Server recommandé. Vous pouvez utiliser le mode de récupération simple SQL Server, bien que le seul point de récupération disponible, si le cluster est perdu, soit la dernière sauvegarde complète. |
Nécessite le mode de récupération complète SQL Server. |
Surcharge des performances |
Il est possible que les performances soient réduites lorsqu’un basculement se produit. |
La mise en miroir à haute disponibilité introduit une latence des transactions, car elle est synchrone. Elle requiert également plus de mémoire supplémentaire et une surcharge du processeur. |
Charge opérationnelle |
Configurée et maintenue au niveau du serveur. |
La charge opérationnelle est supérieure au clustering. Elle doit être configurée et maintenue pour toutes les bases de données. La reconfiguration après le basculement est manuelle. |
Stratégies de redondance des applications de service
La stratégie de redondance que vous appliquez pour protéger des applications de service qui s’exécutent dans une batterie varie selon l’emplacement où l’application de service stocke les données.
Applications de service qui stockent des données dans des bases de données
Pour protéger les applications de service qui stockent des données dans des bases de données, procédez comme suit :
Installez le service sur plusieurs serveurs d’applications afin d’assurer la redondance dans l’environnement.
Configurez le clustering ou la mise en miroir SQL Server pour protéger les données.
Les applications de service suivantes stockent des données dans des bases de données :
Application de Service Business Data Connectivity
Application de service Registre d’application
Il est déconseillé de mettre en miroir la base de données Registre d’application, car elle est uniquement utilisée lors de la mise à niveau des informations de catalogue de données métiers Windows SharePoint Services 3,0 vers SharePoint Foundation 2010.
Application de service de collecte de données relatives à l’utilisation et à l’état
Notes
Il est déconseillé de mettre en miroir la base de données de journalisation de l’application de service de collecte de données relatives à l’utilisation et à l’état.
Service de paramètres d’abonnement Microsoft SharePoint Foundation
Redondance et basculement entre centres de données proches configurés comme batterie unique (batterie « étirée »)
Certaines entreprises ont des centres de données proches avec des connexions à bande passante élevée, ce qui permet de les configurer sous forme d’une batterie unique. On parle dans ce cas de « batterie étirée ». Pour qu’une batterie étirée fonctionne, la latence entre SQL Server et les serveurs Web frontaux doit être inférieure à 1 ms dans un sens avec une bande passante minimale égale à 1 Gbit/s.
Dans ce scénario, vous pouvez assurer la tolérance de panne en suivant l’aide standard pour rendre les bases de données et les applications de service redondantes.
L’illustration suivante montre une batterie étirée.
Batterie étirée
.gif "Batterie de serveurs « étirée »")