Topologies

Cette section décrit certaines topologies (configurations de déploiement) à prendre en compte avant d'installer WebSphere Partner Gateway et les logiciels requis. La topologie que vous choisirez devra être basée sur les facteurs décrits dans la section relative à la planification de l'environnement. La présente section décrit la topologie consolidée, la topologie divisée et la topologie répartie.

Dans les topologies divisées et réparties, vous devez vous assurer que le dossier commun partagé utilise le même point de montage et la même structure de répertoire sur toutes les machines. Prenons le cas où dbloader, le réceptionnaire et la console sont installés sur la machine A, et le gestionnaire de documents sur la machine B. Un lecteur mappé (par exemple Y:) doit être créé sur la machine A. L'utilisateur doit indiquer ce lecteur mappé lorsqu'il est invité à indiquer l'emplacement du dossier partagé commun. Sur la machine B (et toutes les machines suivantes sur lesquelles une instance du gestionnaire de documents doit être installée), la même mappe (Y:)devra être créée et pointée vers le dossier commun partagé.

Topologie consolidée

Cette topologie est la plus simple. Elle consiste en un seul serveur sur lequel sont exécutés les trois composants de WebSphere Partner Gateway (Réceptionnaire, Console de communauté et Gestionnaire de documents). Vous pouvez également installer WebSphere MQ et votre SGDBR sur ce serveur, bien que ces produits devraient être installés sur des serveurs spécialisés distincts.

Topologie divisée

La topologie divisée consiste en un serveur frontal hébergeant le Réceptionnaire et la Console de communauté, et un serveur d'arrière-plan contenant le Gestionnaire de documents. Cette topologie est une topologie d'entrée de gamme destinée à un petit environnement de production, qui optimise votre investissement en matière de logiciels. Notez que WebSphere MQ et SGBDR peuvent être installés sur tout type de système, y compris sur ces serveurs. Pour obtenir une installation optimale, il est préférable de les installer sur des serveurs spécialisés.

Dans le cadre d'une topologie divisée, toutes les instances des trois composants de WebSphere Partner Gateway doivent communiquer avec le même système de fichiers partagés. Si un volume important et une haute disponibilité ne font pas partie de vos exigences, l'hébergement du stockage sur un serveur d'arrière-plan est une solution rentable. Une solution d'arrière-plan est préférable à un stockage frontal pour des questions de sécurité et de performances. Si vous optez pour cette solution, le serveur frontal peut partager des fichiers avec la solution d'arrière-plan via une connexion NFS ou une solution équivalente de partage de fichier.

Remarque :
Dans un déploiement en topologie divisée, la date et l'heure de toutes les machines doivent être synchronisées avec la plus grande précision possible. Les événements qui ont lieu au niveau de la machine hôte du Réceptionnaire lors de la réception de messages sont consignés avec l'horodatage de cette machine. D'autres événements peuvent être impliqués dans le traitement du même message sur la machine du Gestionnaire de documents. Ces événements seront consignés avec l'horodatage de la machine du Gestionnaire de documents. La synchronisation parfaite de la date et de l'heure étant impossible, cela permet d'expliquer des anomalies chronologiques lors de la visualisation des enregistrements de journal sur la console.

Topologie répartie

Si vous disposez d'une grande installation et souhaitez un environnement évolutif et redondant, vous créerez probablement une topologie répartie. Cette topologie consiste en un ou plusieurs serveurs spécialisés pour chaque composant WebSphere Partner Gateway (Réceptionnaire, Console de communauté et Gestionnaire de documents). Vous pouvez avoir, par exemple, un environnement constitué de deux serveurs de Réceptionnaire pour assurer la redondance, quatre serveurs de Console de communauté pour prendre en charge un grand nombre d'utilisateurs de Console de communauté et six serveurs de gestionnaire de documents pour le traitement des documents. Vous pouvez redimensionner cette topologie en ajoutant des serveurs supplémentaires pour le composant qui a besoin de gérer un plus grand volume de documents (Gestionnaire de documents), un plus grand nombre d'utilisateurs (Console de communauté) ou de connexions (Réceptionnaire), selon les besoins.

Dans le cadre d'une topologie répartie, un système NAS externe apparaît comme une bonne solution de stockage partagé. L'environnement est ainsi doté d'une unité de stockage redondante, très performante, indépendante des autres serveurs. Tous les serveurs peuvent établir une connexion NFS (ou une solution de partage de fichiers équivalente) vers le dispositif externe. Votre SGBDR et WebSphere MQ doivent être installés sur des serveurs spécialisés, leur stockage de données ne doit pas obligatoirement être sur des unités NAS.

Conception conseillée

Une fois que vous avez défini une topologie, vous devez considérer l'installation de cette topologie afin d'assurer la redondance et les capacités de reprise après incident. La conception basée sur les Pods est recommandée. Dans cette conception, vous disposez d'un Pod de production primaire. Ce Pod contient tous les composants WebSphere Partner Gateway nécessaires pour gérer une charge de production. Il y a également un Pod de production secondaire, qui peut aussi gérer la charge de production, et un composant Load Balancer permettant de passer de l'un à l'autre. Le Pod de production secondaire assure la redondance. La figure 1 montre comment vous pouvez installer les deux Pods.

Figure 1. Topologie basée sur les Pods
Schéma d'une topologie basée sur des Pods. Ce concept est expliqué en détail dans les paragraphes précédents et suivants.

Un autre Pod, capable de gérer la charge de production peut être installé sur votre site de reprise après incident. Les composants frontaux des trois pods doivent être identiques. Cependant, les composants dorsaux du Pod de reprise après incident doivent être séparés des composants de production. Ainsi, un serveur de base de données distinct, un serveur WebSphere MQ et un système de fichiers partagés sont requis. Vous devez mettre en oeuvre un certain type de synchronisation de données entre les composants de production et les composants dorsaux de reprise après incident. A un instant donné, WebSphere Partner Gateway ne prend en charge qu'un seul environnement de production actif. Vous pouvez également ajouter un Pod de test, qui peut être une installation minimale telle que la topologie consolidée.

Copyright IBM Corp. 2003, 2005