Un grand cluster IBM® WebSphere Application Server est composé de serveurs HTTP frontaux et de serveurs proxy comprenant un équilibreur de charge qui dirige les demandes dans tout le cluster.
Restriction : Pour créer et utiliser un cluster de serveurs d'applications, vous devez posséder
IBM WebSphere Application Server Network Deployment (ND), qui n'est pas fourni avec
IBM Rational Asset Manager.
Vous pouvez aussi réaliser une mise à l'échelle à la fois vertical et horizontal de WebSphere Application Server. Utilisez un serveur de base de données et serveur de fichiers dédiés. Le degré d'échelle possible de WebSphere Application Server et le nombre de serveurs que vous pouvez utiliser dépend du type et de la magnitude des demandes des serveurs et du nombre d'actifs.
- Serveur HTTP IBM
- Le premier niveau est le serveur HTTP qui gère les demandes des clients Web et allège le serveur d'applications de la prise en charge du contenu statique. Il fournit une adresse URL logique regroupant des applications auxiliaires comme l'application IBM Rational Asset Manager,
l'application d'aide de Rational Asset Manager et l'application de développement basé sur des actifs de Rational Asset Manager. Notez que dans une configuration de grande dimension, un serveur mis en antémémoire est déployé à l'avant du serveur HTTP.
- Equilibreur de charge
- Un équilibreur de charge répartit la charge sur plusieurs systèmes. Si vous disposez de plusieurs serveurs HTTP, l'utilisation d'un équilibreur de charge est nécessaire.
S'il s'agit de déploiements de taille modérée, utilisez un équilibreur de charge à base logicielle comme Edge Component. Pour des déploiements plus importants, prenant en charge un grand nombre d'utilisateurs simultanés, utilisez un équilibreur de charge à base matérielle.
- Proxy avec cache mémoire
- Un système proxy avec mémoire cache avant stocke des données d'applications pour des clients dans un cache et allège la charge des autres systèmes serveur. Si votre serveur Rational Asset Manager prend en charge un nombre modéré d'utilisateurs, un seul système proxy avant est alors nécessaire. Si en revanche, votre serveur Rational Asset Manager prend en charge un grand nombre d'utilisateurs simultanés, plusieurs systèmes proxy pourraient s'avérer nécessaires.
- Serveur d'applications
- Le fichier EAR Rational Asset Manager se compose de deux fichiers WAR : le fichier d'application Web et de référentiel et le fichier de services Web. Déployez le fichier EAR de Rational Asset Manager sur toutes les instances de WebSphere Application Server d'un cluster. Rational Asset Manager inclut aussi de l'aide et des fichiers WAR d'IBM Rational Unified Process (RUP) ; le déploiement de ces fichiers WAR n'est pas nécessaire. Si une haute disponibilité est requise pour l'aide et les fonctions de prise en charge de RUP, déployez-les sur une même instance de WebSphere Application Server ou sur un conteneur externe de WebSphere Application Server.
- Application Rational Asset Manager
- Le référentiel de Rational Asset Manager est normalisé pour des recherches et des récupérations de données afin que les données soient stockées afin de permettre des recherches de données, une exploration des artefacts et des téléchargements d'actifs plus efficaces. Pour cela, toutes les instances de serveur Rational Asset Manager génèrent un index local d'actifs et un index local d'artefacts.
Ceci optimise les performances des recherches, allège la charge des bases de données et améliore l'évolutivité dans un environnement en cluster. Les répertoires d'index locaux peuvent agir de meilleure façon qu'un index partagé entre des noeuds.
- Serveur
de bases de données
- Les considérations les plus importantes dans le choix du matériel pour la base de données résident dans le nombre de disques au sien de la machine et le schéma RAID que la machine utilise. Une grappe RAID doit contenir au minimum entre 6 et 10 unités pour chaque processeur. Alors que la mémoire est importante, il n'existe pas de différence significative entre des configurations de serveurs de base de données dotés d'une mémoire de 4 Go et de 8 Go pour 1000 utilisateurs et 50 000 actifs.
- Les besoins en espace disque de la base de données dépendent de nombreux facteurs : le nombre d'actifs, le nombre d'artefacts de chaque actif, le nombre d'espaces d'équipe, le nombre de rôles, le nombre de revues, le nombre de types d'actif, le nombre d'utilisateurs, le volume de transactions sur le serveur (métriques utilisateur) et la quantité de forums de discussion.
- Serveur de fichiers
- Les actifs doivent être partagés sur des instances WebSphere Application Server.
Utilisez un système de fichiers accédé en mode concurrent. Rational Asset Manager accède à ces fichiers uniquement durant des téléchargements amont et aval, une indexation d'artefact et des changements significatifs sur le modèle Rational Asset Manager qui nécessite une mise à jour manifeste des actifs.
Topologies de groupement
Un groupement est la combinaison d'un groupe de machines en une entité logique afin qu'elle soit référencée comme il s'agissait d'une machine. Cette section décrit différentes configurations de clusters ainsi que les principaux avantages et désavantages de chacune.
- Groupement horizontal
- Un groupement horizontal, également appelé "scaling out", consiste à ajouter des machines physiques afin d'accroître les performances ou la capacité d'un pool de clusters. D'une manière générale, un groupement horizontal accroît la disponibilité de l'application en cluster pour le coût d'un accroissement de maintenance.
Un groupement horizontal peut accroître la capacité et le rendement d'une application en cluster ; utilisez ce type de groupement dans la plupart des instances.
- Groupement vertical
- Un groupement vertical, parfois appelé "scaling up", consiste à ajouter des instances WebSphere Application Server à la même machine. Une évolutivité verticale permet de bénéficier des ressources inutilisées des grands serveurs à multitraitement symétrique. Vous pouvez utiliser un groupement vertical pour créer de nombreux processus JVM (machine virtuelle Java) qui, une fois réunis, sont en mesure d'utiliser l'intégralité de la puissance de traitement disponible.
- Groupement horizontal et vertical hybride
- Un groupement hybride est une combinaison de groupements horizontaux et verticaux. Dans cette configuration, des configurations matérielles disparates sont des membres du même cluster. Bénéficiant de davantage de capacité, des machines plus grandes pourraient contenir plusieurs instances de WebSphere Application Server ; des machines plus petites pourraient quant à elles, être mises en cluster en mode horizontal et ne contenir qu'une seule instance de WebSphere Application Server.
- Soyez vigilant lorsque vous utilisez un groupement vertical. Le seul moyen de déterminer ce qui convient à votre environnement et à votre application consiste à ajuster une instance unique d'un serveur d'applications en termes de rendement et de performances, puis de l'ajouter à un cluster et d'ajouter de façon incrémentielle des membres de cluster supplémentaires. Testez les performances et le rendement à mesure que vous ajoutez un membre au cluster. Lorsque vous configurez une topologie d'évolutivité vertical, prenez le soin de toujours contrôler l'utilisation de la mémoire ; n'allez pas au-delà de la quantité d'espace utilisateur adressable ou de la quantité de mémoire physique disponible d'une machine.
Evolutivité
L'évolutivité est la facilité avec laquelle un site peut se développer. Le nombre d'utilisateurs, d'actifs et de communautés associés à une installation Rational Asset Manager donnée doit pouvoir se développer pour prendre en charge un accroissement de charge. L'accroissement de charge peut provenir de nombreuses sources comme l'ajout d'équipes ou de services supplémentaires à l'ensemble des utilisateurs de Rational Asset Manager ou l'importation de larges ensembles d'actifs historiques dans Rational Asset Manager.
L'évolutivité est une donnée architecturale qui détermine la conception de votre architecture.
Bien que vous pourriez améliorer l'évolutivité de votre système en y ajoutant du matériel supplémentaire, cela risque de ne pas améliorer les performances et le rendement.
Le choix entre le groupement vertical (scaling up) et le groupement horizontal (scaling out) se résume généralement à une décision basée sur les préférences, le coût et la nature de votre environnement. Les problèmes de résilience des applications peuvent changer vos préférences.
- Un groupement vertical implémente une évolutivité verticale sur un petit nombre de machines équipées de plusieurs processeurs et dotées de grandes quantités de mémoires d'espace utilisateur adressables.
Ceci permet de prévenir les points de défaillance unique (SPOF) puisque moins de grandes machines composent votre environnement.
- Un groupement horizontal utilise un plus grand nombre de machines plus petites. Dans ce scénario, il est peu probable que la défaillance d'un petit serveur n'entraîne une indisponibilité complète des applications. Toutefois, un groupement horizontal crée davantage de besoins en maintenance.
Disponibilité
Egalement appelée tolérance aux pannes ou résilience, la disponibilité est la capacité d'un système à fournir une continuité opérationnelle malgré des défaillances de composants ou de systèmes.
Les décisions architecturales, comme une évolutivité horizontale comparée à une évolutivité verticale et l'utilisation d'équilibreur de charge de sauvegarde, peut avoir un impact sur la disponibilité de votre application Rational Asset Manager.
Considérons la disponibilité de toutes les ressources partagées, de tous les réseaux et de tous les systèmes de stockage sur disque composant votre environnement Rational Asset Manager.
Dans une conception avec tolérance aux pannes, en cas de défaillance d'une application ou d'un serveur, d'autres membres du cluster peuvent poursuivre les services aux clients.
Il existe deux catégories de reprise en ligne : la reprise en ligne de serveurs et la reprise en ligne de sessions.
Lorsqu'une reprise en ligne de serveur se produit, les sessions du membre défaillant du cluster sont perdues (un utilisateur devra se reconnecter), mais les services sont toujours accessibles au client. S'il s'agit d'une reprise en ligne de sessions, les sessions existantes sont repris par d'autres membres du cluster comme s'il n'y avait pas eu de défaillance du membre du cluster (avec le risque de voir la dernière transaction perdue).
Si vous avez configuré une infrastructure redondante pour prendre en charge une reprise en ligne de serveurs, Rational Asset Manager prendra cela en charge.