Cette section dresse la liste des points à prendre en compte avant l'installation de WebSphere Partner Gateway. Une planification adéquate vous permet de définir la topologie de déploiement qui correspond à vos besoins.
L'immobilisation du système peut affecter considérablement la productivité et la rentabilité de votre activité. Lorsque vous créez un système haute disponibilité, vous garantissez à la communauté de votre concentrateur un système toujours disponible, prêt à fonctionner et à recevoir des documents. Un environnement à haute disponibilité classique permet au système de travailler 99,9 pour cent du temps, certains d'entre eux atteignant même 99,999 pour cent. Les niveaux de disponibilité peuvent diminuer du fait d'événements tels qu'une défaillance ou une surcharge du système, un encombrement ou une attaque du réseau. Pour augmenter la disponibilité, votre système doit être redondant. Pour cela, vous devez disposer dans votre architecture d'au moins deux implémentations de chaque fonction logique (Console de communauté, Réceptionnaire et Gestionnaire de documents) sur des serveurs distincts. Ainsi, si vous installez les trois composants sur un même serveur, un second serveur est nécessaire pour assurer la redondance. Si vous installez chaque composant sur un serveur distinct, il vous faudra alors six serveurs au total pour assurer la redondance. De plus, vous devez également prévoir la création d'un autre ensemble de serveurs dans l'emplacement de la reprise après incident afin de pouvoir exécuter le système à partir de cet emplacement.
Pour créer une implémentation haute disponibilité de WebSphere Partner Gateway, l'infrastructure qui la prend en charge (le réseau, la connexion Internet et même l'alimentation de votre installation) doit également être de type haute disponibilité. Cette condition de haute disponibilité s'applique de la même façon à MQ et à votre SGBDR. Si l'une de ces applications tombe en panne, votre environnement de production s'arrêtera.
WebSphere Partner Gateway évolue de façon horizontale. En d'autres termes, vous pouvez augmenter sa capacité de traitement en ajoutant des instances de ses composants. Le nombre réel de serveurs, d'instances d'un composant spécifique ou la capacité du réseau dont vous aurez besoin dépend des facteurs suivants :
Pour faire face à l'évolution de ces facteurs, vous pourrez redimensionner WebSphere Partner Gateway en ajoutant plusieurs instances de ses composants. Le Réceptionnaire, la Console de communauté et le Gestionnaire de documents peuvent avoir des instances n'importe où, de façon indépendante. Cependant, lors de la création de composants redondants de WebSphere Partner Gateway, certains points doivent être pris en compte :
Notez que si vous redimensionnez WebSphere Partner Gateway, vous devez également redimensionner l'infrastructure qui le prend en charge, notamment WebSphere MQ et votre SGBDR.
Une fois les serveurs configurés, il est important de contrôler les performances de votre système afin de déterminer s'il faut davantage de serveurs pour satisfaire la demande, et à quel moment.
Le stockage de données est un élément clé de votre topologie car c'est une condition préalable à l'installation de WebSphere Partner Gateway. La façon d'aborder les prérequis en matière de stockage partagé dépend de vos besoins en stockage et des réponses que vous apporterez aux questions suivantes :
Si vos besoins dans ces domaines sont faibles, vous pouvez installer le stockage partagé sur le même serveur qu'un ou plusieurs composants de WebSphere Partner Gateway. En revanche, s'ils sont élevés, le stockage partagé doit être installé sur un serveur distinct de WebSphere Partner Gateway. Si la haute disponibilité est une nécessité, prévoyez un produit de stockage en réseau NAS (Network Attached Storage) redondant car il peut être dimensionné indépendamment des serveurs. Notez que votre SGDBR et WebSphere MQ ne doivent pas obligatoirement être installés sur un NAS.
WebSphere Partner Gateway fonctionne au sein d'un environnement de sécurité standard. Cependant, vous devez prendre en compte les éléments suivants :
Si vous utilisez un composant Load Balancer, la Console de communauté nécessite l'activation de sessions avec mise en cache des informations de connexion (également appelées Server Affinity). Ces sessions indiquent au composant Load Balancer que si une demande client est émise par une adresse IP dans un délai configuré, la demande doit être envoyée au même serveur que la fois précédente, au lieu de sélectionner un nouveau serveur.
La console utilise des cookies pour s'assurer que toutes les demandes entrantes exécutées via le navigateur pour une même session vont au même serveur. Lorsque les sessions sont désactivées, chaque requête de la console peut être envoyée par le composant Load Balancer à un serveur différent. Des problèmes peuvent survenir. Par exemple, la console considérera que l'utilisateur n'est pas connecté. L'activation de sessions avec mise en cache des informations de connexion peut avoir un impact sur le dimensionnement puisque les réceptionnaires seront également affectés. Les participants qui ont de gros volumes de documents peuvent faire envoyer leurs documents à la même instance du Réceptionnaire, car le composant Load Balancer verra que la même adresse IP client est utilisée pour chaque demande de document. Il est également possible de n'activer ces sessions que pour les cookies, afin que les Réceptionnaires ne soient pas affectés.