Implementa o jazz.war tanto em servidores principais quanto de backup para que
seja possível utilizar a espera inativa como uma estratégia para 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 Chaves
Antes de decidir usar a configuração de espera inativa, considere os
pontos chaves a seguir:
- Aplicações Jazz, como Rational Team Concert e Rational Quality Manager, são licenciadas para uso como configurações de um único servidor e não podem ser usadas em uma configuração clonada ou em cluster, exceto se forem implementadas em uma
configuração de espera inativa. Nessa configuração, é possível ativar um servidor de backup se o servidor principal falhar ou se uma manutenção precisar ser executada no servidor principal. O armazenamento em cluster para balanceamento de carga ou qualquer coisa diferente
da implementação da configuração de espera inativa não é suportado no momento.
- A configuração de espera inativa não é destinada a fornecer suporte completo ao failover. Se o servidor principal falhar ou se for intencionalmente colocado off-line, alguns usuários podem precisar autenticar novamente para a Web ou terem que aguardar que seus clientes atualizem uma visualização.
- O servidor de backup não é destinado a executar 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 uma comutação for feita para o servidor
de backup, você deve planejar trazer o servidor principal de volta o mais rapidamente 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 é utilizado para o tráfego recebido direto 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 de
alta disponibilidade alta básica:
Tabela 1. Requisitos de Alta Disponibilidade BásicaServidor |
Software |
Sistema operacional |
IBM HTTP Server |
- IBM HTTP Server v6.1.0.17+
- Os plug-ins do servidor da Web para WebSphere Application Server v6.1.0.17+
- Pacote de manutenção WebSphere SDKPK85942
- IBM Key Management v7.0.3.28
|
Windows®, Linux® |
Servidor principal WebSphere Application Server A |
- 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 |