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 Espera Inativa do Rational Team Concert permite que a recuperação do failover ajude a garantir mínimo impacto nas operações de negócios durante interrupções planejadas ou não planejadas do servidor. Para implementar a configuração espera inativa, você deve ter a Enterprise Edition do Rational Team Concert e WebSphere Application Server.
Pontos Principais
Antes de decidir usar a configuração de espera inativa, considere os seguintes pontos principais:
- O Rational Team Concert é licenciado para uso como uma configuração de servidor único e não pode ser usado em uma configuração clonada ou em cluster, exceto se implementado como 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 permite que apenas um servidor esteja ativo a qualquer momento em um repositório; portanto, o servidor de backup (ou Inativo) está configurado para nunca executar Tarefas assíncronas (ou secundárias). 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 a alta disponibilidade básica do Rational Team Concert ao usar 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
|
Windows, Linux |
| Servidor Principal B do WebSphere Application Server |
- WebSphere Application Server v6.1.0.19
- Rational Team Concert v2.0
- Enterprise Edition
|
Windows, Linux |
| Opcional - Servidor de Arquivos, Disco Compartilhado |
Índice Lucene - índice de texto completo |
Windows, Linux |