1.4 Topologies prises en charge

Les sections suivantes traitent des différentes topologies, mises en grappe ou non, que vous pouvez utiliser. Pour plus d’informations sur la configuration de votre serveur d’applications sur une grappe, reportez-vous au site Web suivant qui correspond à votre serveur d’applications :

1.4.1 Serveurs Web, d’applications et de base de données combinés

Cette topologie consiste en un serveur Web, un serveur d’applications et un serveur de base de données situés sur le même nœud. Il s’agit de la plus simple et elle ne doit être utilisée que pour le développement.

1.4.2 Serveurs Web et d’applications combinés, avec un serveur de base de données séparé

Cette topologie peut être utilisée pour la production si la charge sur l’interface utilisateur (y compris le niveau Web) est minimale, avec peu d’utilisateurs.

La combinaison des serveurs Web et d’applications signifie que toutes les recherches Enterprise JavaBeans™ (EJB) sont locales. Cela permet donc d’éviter d’effectuer une recherche distante. De plus, cette topologie permet d’éviter au réseau de faire des aller-retours entre le niveau Web et le niveau des applications.

Toutefois, puisque les deux serveurs sont sur le même nœud, si le niveau Web est compromis, les deux niveaux le sont. Si le niveau Web présente une charge importante, le fonctionnement du serveur d’applications en est affecté, et vice versa. Le temps de réponse de l’utilisateur est généralement affecté lorsque les utilisateurs doivent attendre un temp important avant de pouvoir accéder à une page, à cause des ressources (UC et/ou mémoire) utilisées par le serveur d’applications.

1.4.3 Serveurs d’applications et de base de données combinés, avec serveur Web séparé

La plus simple des topologies pour un environnement de production est un serveur Web ajouté à des serveurs d’applications et de base de données combinés. Utilisez cette topologie uniquement si vous êtes sûr que la charge de vos bases de données sera minimale. Dans ce cas, le serveur Web redirige vers le serveur d’applications. Les avantages de cette topologie sont : faible coût, simplicité et équilibrage de la charge non nécessaire. Ses inconvénients sont : faible redondance, faible évolutivité, impossibilité de mettre à jour ou à niveau, et possibilité de faibles performances en raison d’un nombre trop important de processus de l’UC.

1.4.4 Serveurs Web, d’applications et de base de données séparés

Cette topologie est la plus courante sur les systèmes de production car elle permet l’attribution de ressources séparées à chaque niveau. Dans ce cas, le serveur Web agit comme un proxy sur le niveau Web, sur le serveur d’applications qui héberge les composants Web. Ce mode de fonctionnement procure une sécurité supplémentaire, puisque le serveur d’applications est sécurisé, même si le serveur Web est compromis.

1.4.5 Ajout d’un serveur Web supplémentaire

Vous pouvez ajouter d’autres serveurs Web pour l’évolutivité et le basculement. Lorsque vous utilisez plusieurs serveurs Web, le fichier de configuration du module externe HTTP WebLogic/WebSphere doit être appliqué à chacun d’entre eux. Dans le cas contraire, si vous installez une nouvelle application, il est possible qu’une erreur « 404 Fichier introuvable » se produise lorsqu’un utilisateur tente d’accéder à l’application Web.

1.4.6 Ajout de serveurs d’applications supplémentaires

Cette topologie est utilisée sur les systèmes de production à plus grande échelle. Les serveurs d’applications sont mis en grappe pour une haute disponibilité, un équilibrage de la charge et un basculement (en fonction de la topologie).

La mise en grappe de serveurs d’applications offre les avantages suivants :

  • Possibilité d’utiliser des configurations matérielles moins chères, tout en réalisant de meilleures performances

  • Possibilité de mettre à niveau le logiciel sur les serveurs sans temps mort

  • Une plus haute disponibilité (en cas d’échec du serveur, les autres nœuds de la grappe en récupèrent le traitement)

  • Possibilité d’exploiter des algorithmes d’équilibrage de la charge sur le serveur Web (à l’aide de services d’équilibrage de la charge), ainsi que sur le niveau EJB pour les demandes de traitement

Les composants AEM forms sont généralement liés à l’unité centrale. Ainsi, les performances augmentent donc plus facilement en ajoutant des serveurs d’applications, plutôt qu’en ajoutant de la mémoire ou de l’espace disque sur un serveur existant.

1.4.7 Plusieurs JVM

La juxtaposition verticale de plusieurs JVM offre les avantages suivants :

Augmentation de l’efficacité de traitement : une instance d’un serveur d’applications s’exécute sur un seul processus JVM. Toutefois, les limitations d’accès simultané inhérentes à un processus JVM l’empêchent d’utiliser pleinement la mémoire et la puissance de traitement des systèmes multi-UC. La création d’un processus JVM supplémentaire fournit plusieurs pools de thread, chacun correspondant à un processus JVM associé à chacun des processus du serveur d’applications. Cette correspondance évite les limitations d’accès simultané et permet au serveur d’applications d’utiliser pleinement la puissance de traitement de l’ordinateur.

Equilibrage de la charge : les topologies de juxtaposition verticale peuvent utiliser la fonctionnalité de gestion de la charge de travail de WebLogic Server ou de WebSphere Application Server.

Basculement des processus : une topologie de juxtaposition verticale prend également en charge le basculement entre les membres de la grappe de serveurs d’applications. Si l’une des instances de serveur d’applications se déconnecte, les autres instances de l’ordinateur poursuivent le traitement des requêtes du client.