Implementar o jazz.war nos servidores principal e de backup para que seja possível usar a espera inativa como uma estratégia para failover em ambientes de alta disponibilidade.
A configuração de Espera Inativa permite a recuperação do failover para ajudar a
assegurar o mínimo impacto nas operações de negócios durante interrupções planejadas
ou não planejadas. Para implementar a configuração de espera inativa com IBM®
Rational Team
Concert,
você deve ter a edição Enterprise e o WebSphere Application Server. Para implementar
a configuração de espera inativa com IBM
Rational Quality
Manager,
você deve ter a edição Standard e o WebSphere Application Server.
Pontos Principais
Antes de decidir usar a configuração de espera inativa, considere os seguintes pontos principais:
- Aplicativos Jazz, como
Rational
Team Concert e Rational
Quality Manager,
são licenciados para uso como configurações de servidor único e não podem ser utilizados em uma configuração de
cluster ou clonada, exceto se forem implementados em uma configuração de espera inativa. Nesta configuração, é possível ativar um servidor de backup se o servidor principal falhar ou se a manutenção precisar ser executada no servidor principal. Não é suportado atualmente o armazenamento em cluster para balanceamento de carga ou qualquer coisa diferente da implementação da configuração de espera inativa.
- A configuração de espera inativa não se destina a fornecer suporte completo para failover. Se o servidor principal falhar ou se ele estiver intencionalmente off-line, alguns usuários poderão precisar autenticar-se na Web novamente ou esperar que seu cliente atualize uma visualização.
- O servidor de backup não se destina a ser executado por períodos estendidos no lugar do servidor principal.
Importante: O Rational
Team Concert e o Rational
Quality Manager permitem
que apenas um único servidor esteja ativo por vez para um repositório; dessa forma, o servidor de backup (ou Inativo) é configurado para nunca executar tarefas assíncronas (ou em plano de fundo). Se um comutador for feito para o servidor de backup, você deve planejar fazer backup do servidor principal o mais rápido possível.
Topologia de Implementação
O diagrama de topologia a seguir ilustra a configuração para alta disponibilidade básica ao utilizar a espera inativa. Na figura a seguir, o IBM HTTP Server é usado para direcionar o tráfego recebido para um dos dois WebSphere Application Servers, Servidor Principal A ou Servidor de Backup B. Os servidores WebSphere representam um nó principal e secundário no cluster. Ambos são membros da mesma célula de cluster. Além dos nós do WebSphere, há um servidor LDAP, um servidor de arquivos (para índice Lucene) e um servidor de Banco de Dados.
Requisitos
A tabela a seguir lista os requisitos básicos de alta disponibilidade:
Tabela 1. Requisitos Básicos de Alta Disponibilidade| Servidor |
Software |
Sistema operacional |
| Servidor HTTP daIBM |
- Servidor HTTP da IBM v6.1.0.17+
- Plug-ins do servidor da Web para WebSphere Application Server v6.1.0.17+
- Pacote de manutenção do WebSphere SDKPK85942
- IBM Key Management v7.0.3.28
|
Windows®, Linux® |
| Servidor Principal A do WebSphere Application Server |
- WebSphere Application Server v6.1.0.19
- Rational
Team Concert v2.0
- Enterprise Edition ou Rational
Quality Manager Standard
Edition
|
Windows, Linux |
| Servidor de Backup WebSphere Application Server B |
- WebSphere Application Server v6.1.0.19
- Rational
Team Concert v2.0
- Enterprise Edition ou Rational
Quality Manager Standard
Edition
|
Windows, Linux |
| Opcional - Servidor de Arquivos, Disco Compartilhado |
Índice Lucene - índice de texto completo |
Windows, Linux |