Despliegue jazz.war tanto en los servidores primarios como en los de respaldo para poder utilizar el estado de espera como una estrategia en caso de fallos en entornos de alta disponibilidad.
La configuración Desocupado en espera permite la recuperación después de una migración
tras error para ayudar a garantizar un impacto mínimo en las operaciones empresariales durante interrupciones planificadas o inesperadas del servidor. Para implementar la
configuración desocupado en espera con IBM® Rational Team Concert,
debe disponer de la edición Enterprise y de WebSphere Application Server. Para implementar la configuración
desocupado en espera con IBM Rational Quality Manager,
debe disponer de la edición Standard y de WebSphere Application Server.
Puntos clave
Antes de decidir utilizar la configuración desocupado en espera, tenga en cuenta lo siguiente:
- Las aplicaciones Jazz como, por ejemplo, Rational Team Concert y
Rational Quality Manager,
tienen licencia para utilizar configuraciones de un solo servidor y no se pueden utilizar en configuraciones clonadas o en clúster,
excepto si se implementan en una configuración de desocupado en espera. En esta configuración puede activar un servidor de respaldo si el servidor primario falla, o si necesita realizar el mantenimiento en el servidor primario. No está soportada la clusterización del equilibrio de carga u otra cosa que no sea la implementación de la configuración desocupada en espera.
- La configuración desocupada en espera no pretende proporcionar un soporte completo en caso de fallo. Si el servidor primario falla o si está intencionadamente fuera de línea, es posible que algunos usuarios necesiten autenticarse a la web de nuevo, o esperar a que el cliente actualice una vista.
- El servidor de respaldo no debe ejecutarse por periodos largos en sustitución del servidor primario.
Importante: Rational Team Concert y
Rational Quality Manager permiten sólo que un único
servidor esté activo en un momento determinado en un repositorio; por lo tanto, el servidor de copia de seguridad (o desocupado) está configurado
de forma que nunca ejecute tareas asíncronas (o en segundo plano). Si se conmuta el servidor de respaldo, debe planificar que se active la copia de seguridad del servidor primario lo antes posible.
Topología de despliegue
El diagrama de topología siguiente muestra la configuración de la alta
disponibilidad básica cuando se utiliza desocupado en espera. En la siguiente figura,
el servidor IBM HTTP se utiliza para dirigir el tráfico entrante a uno de los dos servidores de aplicaciones WebSphere, servidor primario A o servidor de respaldo B. Los servidores WebSphere representan un nodo primario o secundario en el clúster. Ambos son miembros de la misma celda del clúster. Además de los nodos WebSphere, existe un servidor LDAP, un servidor de archivo (para índice Lucene) y un servidor de base de datos.
Requisitos
La siguiente tabla recoge los requisitos básicos de alta disponibilidad:
Tabla 1. Requisitos básicos de alta disponibilidad| Servidor |
Software |
Sistema operativo |
| Servidor IBM HTTP |
- IBM HTTP Server v6.1.0.17+
- Plug-ins del servidor web del servidor de aplicaciones WebSphere v6.1.0.17+
- Paquete de mantenimiento WebSphere SDKPK85942
- IBM Key Management v7.0.3.28
|
Windows®, Linux® |
| Servidor A primario de aplicaciones WebSphere |
- Servidor de aplicaciones WebSphere v6.1.0.19
- Rational Team Concert v2.0
- Edición Enterprise o Rational Quality Manager - Edición Standard
|
Windows, Linux |
| Servidor B de respaldo de WebSphere Application Server |
- Servidor de aplicaciones WebSphere v6.1.0.19
- Rational Team Concert v2.0
- Edición Enterprise o Rational Quality Manager - Edición Standard
|
Windows, Linux |
| Opcional - Servidor de archivos, disco compartido |
Índice Lucene - índice de texto completo |
Windows, Linux |