En este apartado se describen algunas de las topologías (configuraciones de despliegue) que se deben considerar antes de instalar Business Integration Connect así como el software de requisito previo. La topología que elija debe basarse en los factores que se describen en la planificación del entorno. Las topologías descritas en este apartado son la topología consolidada, la topología de división y la topología distribuida.
Esta topología es la más simple. Consta de un solo servidor que ejecuta los tres componentes de Business Integration Connect (receptor, consola de comunidad y gestor de documentos). También puede poner WebSphere MQ y RDBMS en el servidor, si bien estos productos deberían estar en servidores dedicados independientes.
La topología de división consta de un servidor frontal que contiene los componentes receptor y consola de comunidad y de un servidor de fondo que contiene el componente gestor de documentos. Esta topología es una topología de nivel de entrada para un entorno de producción y aumenta la inversión del software. Observe que WebSphere MQ y RDBMS pueden encontrarse en cualquier lugar, incluso en estos servidores. La mejor implementación es tenerlos en servidores dedicados.
En una topología de división (servidores frontales y de fondo), todas las instancias de los tres componentes de Business Integration Connect tienen que comunicarse con el mismo sistema de archivos compartidos. Si no importan los factores de gran volumen o alta disponibilidad, el alojamiento del almacenamiento en el servidor de fondo es una solución nada cara. El servidor de fondo es preferible al frontal por razones de rendimiento y seguridad. Cuando se emplea esta solución, el servidor frontal puede utilizar una conexión NFS o equivalente para compartir archivos con el servidor de fondo.
Si tiene una instalación grande y desea un entorno altamente escalable y altamente redundante, probablemente va a crear una topología distribuida. Esta topología consta de un servidor dedicado (o más de uno) para cada componente de Business Integration Connect (receptor, consola de comunidad y gestor de documentos). Por ejemplo, puede tener un entorno que requiera dos servidores de receptor para que haya redundancia, cuatro servidores de consola de comunidad para dar soporte a un gran cantidad de usuarios de la consola de comunidad y seis gestores de documentos para procesar documentos. Puede escalar esta topología añadiendo servidores adicionales para el componente que tenga que gestionar un nivel superior de proceso de documentos (gestor de documentos), usuarios (consolas de la comunidad) o conexiones (receptores) según convenga.
En una topología distribuida, un dispositivo NAS externo representa una buena solución para el almacenamiento compartido. Esto ofrecerá al entorno un dispositivo de almacenamiento redundante y de alto rendimiento que es independiente de los demás servidores. Todos los servidores pueden crear una conexión NFS externa o una solución de compartición de archivo equivalente, con el dispositivo externo. RDBMS y WebSphere MQ deben estar en servidores dedicados y el almacenamiento de datos que hagan no debe ser en dispositivos NAS.
Tras decidir la topología que va a utilizar, debería considerar cómo implementar la topología para proporcionar las funciones de recuperación en caso de desastre y de redundancia. Se recomienda el diseño basado en Pod. En este diseño, tiene un Pod de producción principal. Este Pod contiene todos los componentes de Business Integration Connect necesarios para gestionar una carga de producción. Existe un Pod de producción secundario, que también puede gestionar cargas de producción y un equilibrador de cargas par conmutar entre los dos. El Pod de producción secundario proporciona redundancia. En la Figura 1 se muestra cómo puede implementar los dos Pod:
Figura 1. Topología basada en Pod
En el sitio de recuperación en caso de desastre podría haber otro Pod capaz de gestionar la carga de producción. Los componentes frontales y de fondo de los tres Pod deben ser idénticos. Sin embargo, los componentes de fondo para el Pod de recuperación en caso de desastre debe estar separado de los componentes de producción. Por tanto, es necesario un servidor de base de datos independiente, un servidor WebSphere MQ y un sistema de archivos compartidos. Tendrá que implementar algunos formularios de sincronización de datos entre los componentes de producción y de recuperación en caso de desastre. Business Integration Connect sólo soporta el entorno de producción activa simple en cualquier momento dado. También puede añadir un Pod de prueba, que puede representar una implementación mínima como la topología consolidada.
En los procedimientos siguientes se describe cómo instalar, actualizar, arrancar, realizar pruebas, resolver problemas y desinstalar Business Integration Connect en un sistema Linux, Solaris o AIX.
Los procedimientos de este capítulo son específicos para Linux. Las vías de acceso pueden variar un poco para los entornos AIX y Solaris.
Este capítulo contiene los apartados siguientes: