En este apartado se enumeran algunas de las cosas que debería tener en cuenta antes de instalar WebSphere Partner Gateway. La planificación adecuada le permite decidir la topología de despliegue que se ajusta a sus requisitos.
El tiempo de inactividad del sistema puede afectar seriamente la productividad y rentabilidad de su empresa. Cuando se crea un sistema de alta disponibilidad, se está garantizando a la comunidad del concentrador que el sistema siempre está activo, en ejecución y preparado para recibir documentos. Un entorno de alta disponibilidad típico garantiza que el sistema funciona al 99,9 por ciento consiguiendo que algunos sistemas lo mantengan el 99,999 por ciento del tiempo. Los niveles de disponibilidad pueden disminuir debido a los sucesos del tipo anomalía del sistema, sobrecarga del sistema, congestión de la red y ataques a la red. Para maximizar la disponibilidad deberá proporcionar información sobre la redundancia del sistema. Puede hacerlo llevando a cabo al menos dos implementaciones de cada función lógica (Consola de comunidad, receptor y gestor de documentos) en distintos servidores de su arquitectura. Por consiguiente, si coloca los tres componentes en un servidor, necesitará un segundo servidor para que proporcione la redundancia. Si separa cada componente en su propio servidor, necesitará seis servidores en total para que proporcionen redundancia. Asimismo, debería plantearse crear otro conjunto de servidores en la ubicación de recuperación en caso de error grave de forma que puede ejecutar el sistema desde esa ubicación.
Para crear una implementación altamente disponible de WebSphere Partner Gateway, su infraestructura de soporte (como por ejemplo, red, conexión a Internet e incluso alimentación que llega al recurso) también deberá tener una gran disponibilidad. El requisito de alta disponibilidad también se aplica a MQ y a RDBMS. Si alguna de estas aplicaciones de soporte falla, el entorno de producción también fallará.
WebSphere Partner Gateway se escala horizontalmente. Es decir, se aumenta el proceso de disponibilidad añadiendo instancias de sus componentes. El número real de servicios, instancias de un componente en particular o de la capacidad de red que pueda necesitar dependerá de los factores siguientes:
A medida que estos factores van cambiando, puede escalar WebSphere Partner Gateway añadiendo múltiples instancias de sus componentes. Las instancias del receptor, la Consola de comunidad y el gestor de documentos pueden residir en cualquier lugar de forma independiente. Sin embargo, hay que tener en cuenta algunas cosas cuando se creen componentes redundantes de WebSphere Partner Gateway:
Tenga en cuenta que, cuando se escala WebSphere Partner Gateway, también se debe escalar la infraestructura de soporte como, por ejemplo, WebSphere MQ y RDBMS.
Tras configurar los servidores, es importante supervisar el rendimiento del sistema para determinar si hacen falta (y cuándo) servidores adicionales para satisfacer las demandas.
El almacenamiento de datos es un componente clave en la topología, ya que se trata de un requisito previo de WebSphere Partner Gateway. La forma que se satisface el requisito de almacenamiento compartido depende de las necesidades de almacenamiento y de las respuestas a las preguntas siguientes:
Si no tiene muchos requisitos para estos temas, puede plantearse implementar el almacenamiento compartido en el mismo servidor como un componente (o más) de WebSphere Partner Gateway. De lo contrario, debería estar en un servidor independiente de WebSphere Partner Gateway. Cuando la alta disponibilidad es un requisito, considere un producto NAS redundante porque puede llevar a cabo el escalado independientemente de los servidores. Observe que RDBMS y WebSphere MQ no deben estar en NAS.
WebSphere Partner Gateway funcionará en un entorno estándar seguro. Sin embargo, debería tener en cuenta lo siguiente:
La Consola de comunidad requiere que se habiliten las sesiones problemáticas (que también se denominan Afinidad de servidores) si se utiliza un equilibrador de cargas. Las sesiones problemáticas se utilizan para indicar al equilibrador de cargas que si una solicitud de cliente viene de la misma dirección IP en un periodo de tiempo configurado, la petición se debe enviar al mismo servidor especificado la última vez en lugar de seleccionar un nuevo servidor.
La consola utiliza cookies para garantizar que todas las solicitudes entrantes, a través del navegador, para una sesión van al mismo servidor. Sin las sesiones problemáticas activadas, el equilibrador de cargas puede enviar cada solicitud de la consola a un servidor diferente. Esto puede producir problemas. Por ejemplo, la Consola no considerará que el usuario ha iniciado sesión. Si se activan las sesiones problemáticas en el nivel de dirección IP puede impactar la acción de escalada porque los receptores también se verán afectados. Los participantes con volúmenes elevados de documentos pueden enviar los documentos a la misma instancia receptora cada vez porque el equilibrador de cargas verá la misma dirección IP cliente utilizada para cada solicitud de documento. Otra opción es habilitar las sesiones problemáticas sólo para cookies para que los receptores no se vean afectados.