Planifier la tolérance aux pannes et la disponibilité dans Project Server 2007
Mis à jour: octobre 2008
Dernière rubrique modifiée : 2015-02-27
Les expressions « tolérance aux pannes » et « disponibilité » font référence à la capacité d’un environnement multiserveur à accepter des connexions et à fonctionner normalement même lorsqu’un ou plusieurs composants de la batterie de serveurs ne sont pas opérationnels. La disponibilité implique la redondance et peut inclure également un mécanisme de basculement et quelques autres caractéristiques.
Vous pouvez utiliser les stratégies suivantes pour améliorer la tolérance aux pannes de votre déploiement Microsoft Office Project Server 2007 :
Mise en clusters
Redondance matérielle
Configuration RAID
Redondance de rôle de serveur
Envoi de journaux
Serveurs de secours
Cet article fournit davantage d’informations sur chacune de ces stratégies. Vous pouvez appliquer ces stratégies individuellement ou combinées. Comme chaque stratégie a un coût associé, il est important d’examiner le rapport coût/avantage pour chacune avant de l’appliquer à votre organisation.
Disponibilité
Il est recommandé d’examiner les besoins en disponibilité lors de la conception de base de la solution Office Project Server 2007. Vous pouvez également améliorer la disponibilité une fois la solution déployée. D’un point de vue opérationnel, il est recommandé de déployer et d’ajuster la solution de base dans une batterie de serveurs, puis de tester les solutions de disponibilité.
Qu’est-ce que la disponibilité ?
La disponibilité est le degré auquel un système tel que Office Project Server 2007 est perçu comme disponible par les utilisateurs. Garantir la disponibilité signifie garantir qu’un système est résilient, c’est-à-dire que les incidents qui affectent le service se produisent rarement et que l’action opportune et efficace est appliquée dans ce cas. Les stratégies de disponibilité réduisent la perception par les utilisateurs des temps d’arrêt planifiés et non planifiés.
L’une des mesures les plus courantes de la disponibilité est le pourcentage du temps de fonctionnement exprimé sous forme de 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 disponibilité égal à 99,999 présente une disponibilité de 5 neufs.
Le tableau ci-dessous établit la correspondance entre le nombre de neufs et les équivalents en durées calendaires.
| Pourcentage de temps d’activité acceptable | Temps quotidien d’immobilisation | Temps mensuel d’immobilisation | Temps annuel d’immobilisation |
|---|---|---|---|
95 |
72 minutes |
36 heures |
18 jours |
99 |
14 minutes |
7 heures |
4 jours |
99,9 |
86 secondes |
43 minutes |
9 heures |
99,99 |
8,6 secondes |
4 minutes |
53 minutes |
99,999 |
0,8 secondes |
26 secondes |
5 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 du temps de fonctionnement annuel, mensuel et quotidien :
% Temps de fonctionnement/an = 100 \endash (8760 \endash nombre total d’heures d’indisponibilité par an) / 8760
% Temps de fonctionnement/mois = 100 \endash ((24 * nombre de jours dans le mois) \endash nombre total d’heures d’indisponibilité dans ce mois) / (24 * nombre de jours dans le mois)
% Temps de fonctionnement/semaine = 100 \endash (168 \endash nombre total d’heures d’indisponibilité dans cette semaine) / 168
Ce que la disponibilité ne signifie pas
La disponibilité n’est pas la protection et la récupération des données, ni la récupération après incident. Vous devez disposer d’une protection des données distincte et de plans de récupération après incident sur tout système hautement disponible.
En outre, la disponibilité n’est pas la gestion de la continuité des opérations (BCM). La gestion BCM se compose des prises de décision, des processus et des outils que vous mettez en place à l’avance afin de gérer des situations de crise. Une crise peut être un événement local, régional ou national ou peut concerner votre entreprise uniquement.
Coût 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, telles que des scripts personnalisés pour le basculement et la récupération ;
la complexité opérationnelle supplémentaire.
Les coûts inhérents à la disponibilité doivent être évalués en fonction des besoins de votre entreprise : les solutions au sein d’une organisation n’exigent probablement pas toutes le même niveau de disponibilité. Vous pouvez proposer différents niveaux de disponibilité pour différents sites, différents services (par exemple, recherche et analyse décisionnelle) ou différentes batteries de serveurs.
La disponibilité constitue un élément essentiel pour lequel les groupes informatiques proposent des contrats de niveau de service qui établissent des exigences auprès de groupes de clients. De nombreuses entreprises informatiques proposent divers contrats de niveau de service correspondant à différents niveaux de facturation.
À propos de la redondance
La redondance est un aspect fondamental de la disponibilité. La redondance inclut l’utilisation de plusieurs serveurs dans un environnement à charge équilibrée pour améliorer les performances de la batterie de serveurs ou la faire évoluer afin de prendre en charge des utilisateurs supplémentaires. La redondance inclut également l’utilisation de composants de secours identiques, tels que des alimentations ou de l’équipement réseau, pour fournir une fonctionnalité continue en cas de panne du composant principal.
Cet article explique comment implémenter des serveurs redondants dans une batterie de serveurs Office Project Server 2007.
Office Project Server 2007 prend en charge des batteries de serveurs évolutives en termes de capacité, de performances et de disponibilité. En général, la capacité est le premier critère qui permet de déterminer le nombre de serveurs de départ. Après la prise en compte des performances, la disponibilité joue également un rôle dans la détermination du nombre de serveurs et de la taille ou de la capacité des serveurs dans une batterie de serveurs. L’ajout de serveurs supplémentaires pour répondre à ces objectifs augmente également la disponibilité globale de votre service.
Détermination des besoins 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 de serveurs, répondez aux questions suivantes :
Si Office Project Server 2007 devient indisponible, les employés de l’entreprise pourront-ils exercer convenablement leurs fonctions ?
Si Office Project Server 2007 devient indisponible, les transactions avec les partenaires et les clients seront-elles interrompues, avec à la clé la perte possible de contrats et de clients ?
Si vous avez répondu oui à l’une de ces questions, vous devez investir dans une solution de disponibilité.
Même si cet article traite principalement de la disponibilité de Office Project Server 2007, le temps d’activité du système est également affecté par les autres composants du système. En particulier, prenez en compte les éléments suivants :
Vous devez vérifier que les dépendances d’infrastructure (par exemple, alimentation électrique, refroidissement, réseau, annuaire et protocole/serveur SMTP) sont complètement redondantes.
Choisissez un mécanisme de commutation pour le système, DNS ou matériel d’équilibrage de la charge, répondant à vos besoins. Les articles ci-dessous indiquent les méthodes conseillées pour les serveurs Web d’équilibrage de la charge :
Mise en clusters
La mise en clusters peut protéger votre système contre une panne d’application ou du système d’exploitation. Vous pouvez également effectuer de nombreuses tâches sur les ordinateurs en cluster sans les passer en mode hors connexion, notamment mettre à niveau une application ou le système d’exploitation ou installer un service pack ou une mise à jour.
Les clusters de serveurs sont conçus pour maintenir des applications disponibles plutôt que pour protéger les données. Pour la protection contre les virus, l’altération et les autres menaces sur les données, vous avez besoin d’une solide protection des données et de plans de récupération. La technologie de clusters ne peut pas protéger contre les défaillances causées par des virus, des logiciels endommagés ou des erreurs humaines.
Gestion de clusters SQL Server de basculement
Les clusters de basculement sont conçus pour les applications avec état. Ces applications possèdent un état en mémoire de longue durée ou des états de données volumineux et fréquemment mis à jour.
Les clusters de basculement offrent une disponibilité élevée car ils permettent le basculement des ressources. Ils maintiennent également les connexions des clients aux applications et aux services.
Dans les clusters de basculement, les nœuds partagent l’accès aux données. Nœuds peuvent être actifs ou passifs et la configuration de chacun dépend du mode d’exploitation (actif ou passif) et de la configuration du basculement dans le cluster. Un serveur qui est désigné pour gérer le basculement doit être dimensionné afin de gérer la charge de travail du nœud en panne en plus de sa propre charge de travail.
Dans les déploiements de Office Project Server 2007, vous pouvez gérer les clusters de basculement avec SQL Server.
Clusters à charge équilibrée
Les clusters à charge équilibrée sont des groupes d’ordinateurs identiques, généralement clonés, qui servent à améliorer la disponibilité des serveurs Web, des serveurs ISA (Microsoft Internet Security and Acceleration) (pour les serveurs proxy et pare-feu) et des autres applications qui reçoivent le trafic TCP (Transmission Control Protocol) et UDP (User Datagram Protocol). Les nœuds de cluster étant généralement des clones identiques les uns des autres, ils peuvent fonctionner indépendamment ; tous les nœuds d’un cluster sont actifs.
Office Project Server 2007 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 Microsoft Windows Server 2003. L’équilibrage de la charge réseau s’exécute sur les serveurs Web frontaux 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 d’équilibrage de charge) s’exécute sur les serveurs Web frontaux, elle utilise les ressources du système Web frontal, ce qui limite les ressources que vous pouvez utiliser pour servir les pages Web. Toutefois, l’impact sur les ressources système n’est pas significatif, et une solution logicielle peut gérer jusqu’à 32 serveurs Web frontaux.
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 du site Web vers les serveurs Web frontaux. Il est plus coûteux à installer que des logiciels, mais il n’affecte pas les ressources des serveurs Web frontaux. Office Project Server 2007 est utilisable 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 cyclique avec DNS (Domain Name System). L’équilibrage de charge DNS cyclique peut utiliser des ressources importantes sur les serveurs Web frontaux, est plus lent que l’équilibrage de charge matériel ou logiciel et n’est pas recommandé pour une utilisation avec Office Project Server 2007. En outre, l’équilibrage de charge DNS cyclique ne prend pas en compte la charge de session lors du routage d’un utilisateur vers un serveur, qui peut entraîner la surcharge d’un serveur.
Redondance matérielle
Vous pouvez fournir une tolérance aux pannes de votre déploiement Office Project Server 2007 en déployant des configurations matérielles supplémentaires qui dupliquent la configuration matérielle de votre organisation. De cette façon, si un chemin d’accès d’entrée/sortie de données ou si les composants matériels physiques d’un serveur (tel qu’ordinateur, réseau et composants SAN) tombent en panne, le système n’est pas affecté. Le matériel que vous utilisez pour minimiser les points de défaillance uniques varie selon les composants que vous souhaitez rendre redondants. Les fournisseurs de matériel incluent généralement le matériel dupliqué dans leur solution de stockage.
Configuration RAID
La configuration RAID (réseau redondant de disques indépendants) permet de renforcer la tolérance aux pannes de votre déploiement Office Project Server 2007. RAID stocke des données identiques sur plusieurs disques à des fins de redondance, d’amélioration des performances et d’augmentation du temps moyen entre pannes (MTBF). Dans une configuration RAID, une partie de la capacité de stockage physique contient des informations redondantes concernant les données enregistrées sur les disques durs. Ces informations redondantes sont soit des informations de parité (dans le cas d’un volume RAID-5), soit une copie intégrale séparée des données (dans le cas d’un volume en miroir). Elles permettent la régénération des données si un des disques ou le chemin d’accès tombe en panne, ou si un secteur sur le disque ne peut pas être lu.
Pour vous assurer que les ordinateurs qui exécutent Office Project Server 2007 continuent de fonctionner correctement en cas de défaillance d’un seul disque, vous pouvez utiliser les disques miroirs ou l’agrégation par bande avec parité RAID sur les disques durs de votre déploiement Office Project Server 2007. Les disques miroir et l’agrégation par bande avec parité créent des données redondantes pour les données sur vos disques durs.
Les bases de données Office Project Server 2007 effectuent des E/S intensives. Pour cette raison, nous vous recommandons RAID 10 pour des performances et une redondance optimales des lecteurs contenant les bases de données Office Project Server 2007.
L’utilisation des configurations RAID n’évite pas les fichiers endommagés ou d’autres erreurs de fichiers. Pour cette raison, n’utilisez pas les configurations RAID comme une alternative aux sauvegardes courantes des données importantes sur vos serveurs.
Comme les journaux des transactions et les fichiers de base de données sont essentiels au fonctionnement des ordinateurs qui exécutent Office Project Server 2007, vous pouvez conserver ces fichiers sur des disques physiques distincts. Vous pouvez également utiliser les disques miroirs ou l’agrégation par bande avec parité RAID afin d’éviter que la défaillance d’un seul disque dur physique provoque une panne de votre base de données Office Project Server 2007.
Si votre environnement contient un réseau SAN (Storage Area Network), vous disposez peut-être déjà de la redondance disque nécessaire pour votre déploiement. Dans un environnement SAN, nous vous recommandons de ne pas placer votre déploiement Office Project Server 2007 et ses composants associés sur la même pile de disques que les autres applications aux E/S intensives, car cela pourrait entraîner une dégradation des performances. Les données Office Project Server 2007 sont optimisées pour les lectures séquentielles, ce qui est idéal dans un environnement SAN.
Redondance de rôle de serveur
La topologie de serveurs de base que vous choisissez dépend du degré de redondance que doivent présenter les rôles de serveur d’applications. Cette section décrit les rôles de serveur d’applications par rapport aux options de redondance correspondantes.
Rôles qui peuvent être redondants
Ces rôles de serveur d’applications peuvent être déployés 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 de ces rôles de serveur reste identique. Si l’un des ordinateurs serveurs tombe en panne, aucune donnée enregistrée n’est perdue. Les serveurs Web répartissent automatiquement la charge exercée sur les demandes adressées à ces rôles de serveur entre les ordinateurs serveurs d’applications disponibles.
Le service d’application Project d’Office Project Server 2007 peut être déployé de manière redondante. Cela permet un meilleur débit pour les requêtes de données PWA et peut augmenter la capacité de votre déploiement. Toutefois, déployer le service d’application Project Server sur plusieurs serveurs n’augmente pas la disponibilité de la batterie de serveurs. Si un des serveurs tombe en panne, la batterie de serveurs ne détecte pas automatiquement la panne et continue à envoyer des requêtes au serveur du service d’application Project Server en panne tant que celui-ci n’est pas retiré manuellement de la batterie de serveurs.
Rôles qui ne peuvent pas être redondants
Certains rôles de serveur d’application que vous pouvez activer dans Office Project Server 2007 ne peuvent pas être redondants, comme la recherche Windows SharePoint Services 3,0. Ce rôle de serveur d’application peut être déployé sur plusieurs serveurs ; cependant, les multiples serveurs ne sont pas redondants. Ce rôle de serveur est configuré pour analyser le contenu et générer des index de contenu. Si vous déployez ce rôle sur plusieurs serveurs, chaque serveur analyse un contenu différent.
Redondance de serveur de bases de données
Le rôle de serveur de base de données affecte la disponibilité de votre solution plus que tout autre rôle. Si un serveur Web ou un serveur d’application tombe en panne, ces rôles peuvent être rapidement restaurés ou redéployés. Toutefois, si un serveur de base de données tombe en panne, votre solution dépend de la restauration du serveur de base de données. Cela peut éventuellement inclure la régénération du serveur de base de données, puis la restauration des données à partir du support de sauvegarde. Dans ce cas, vous risquez éventuellement de perdre les données nouvelles ou modifiées en remontant à votre dernière sauvegarde, selon la façon dont SQL Server est configuré. En outre, la solution sera totalement indisponible pendant la période où le rôle de serveur de base de données sera restauré.
Quel que soit le système, il est recommandé de collaborer avec les fabricants de matériel afin de disposer d’un matériel tolérant aux pannes adéquat, notamment de baies RAID.
Lors de la planification de la tolérance aux pannes des composants, tenez compte des points suivants :
La redondance totale de chaque composant dans un serveur peut être impossible ou 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.
Envoi de journaux
Avec Microsoft SQL Server, vous pouvez utiliser l’envoi de journaux pour alimenter les journaux de transactions d’une base de données à l’autre en continu. La sauvegarde continue des journaux de transactions d’une base de données source, puis la copie et la restauration des journaux dans une base de données de destination, conservent la base de données de destination synchronisée avec la base de données source. L’envoi des journaux fournit une méthode automatisée de maintenance d’un serveur de secours.
Serveurs de secours
Un serveur de secours est un second serveur qui peut être mis en ligne si un serveur de production principal tombe en panne. Les mêmes composants logiciels qui sont installés sur le serveur principal sont installés sur le serveur de secours. L’utilisation d’un serveur de secours permet aux utilisateurs de continuer à travailler avec des données Office Project Server 2007 si le serveur principal devient indisponible.
Un serveur de secours peut également être utilisé lorsqu’un serveur principal est indisponible en raison de maintenance planifiée. Par exemple, si vous devez déconnecter le serveur principal pour une mise à niveau matérielle ou logicielle, vous pouvez utiliser le serveur de secours jusqu’à ce que le serveur principal soit remis en ligne.
Le facteur le plus important à prendre en considération lors de l’utilisation de serveurs de secours est que le matériel, les mises à jour logicielles et les mises à jour du microprogramme sur un serveur de secours doivent être identiques à ceux du serveur principal que le serveur de secours est conçu pour remplacer.
Si le serveur de secours est un serveur de base de données, il doit contenir une copie des bases de données sur le serveur principal. Si le serveur principal passe en mode hors connexion et que le serveur de secours est mis en ligne, lorsque le serveur principal redevient disponible, les modifications apportées aux copies de la base de données qui se trouvent sur le serveur de secours doivent être copiées sur le serveur principal. Dans le cas contraire, ces modifications sont perdues. Lorsque les utilisateurs recommencent à utiliser le serveur principal, les bases de données du serveur principal doivent être sauvegardées et copiées sur le serveur de secours.
L’envoi de journaux permet de garantir que le serveur de secours reste synchronisé avec le serveur principal. Si le serveur principal tombe en panne, ou même si simplement une seule base de données tombe en panne, les bases de données du serveur de secours peuvent être rendues disponibles aux processus des utilisateurs. Tout processus utilisateur qui ne peut pas accéder au serveur principal doit utiliser à la place le serveur de secours.
Si vous avez des serveurs Web frontaux distincts dans votre déploiement, vous pouvez installer le service d’application Project Server sur les serveurs Web frontaux et les laisser désactivés. Puis, en cas de panne d’un de vos serveurs Office Project Server 2007, vous pouvez activer le service d’application Project Server sur le serveur Web frontal pour facilement mettre en ligne un serveur de secours.