Sugestões para trocar um servidor de produção

Question

Antecedentes

Minha equipe está investigando um problema em nosso ambiente de produção ( veja Stack Overflow ). Examinamos detalhadamente a camada de aplicativo (por exemplo, código, logs, etc.) e também fizemos alguns sniffing de pacote de baixo nível, mas sem sucesso. O curioso é que esse problema ocorre apenas na produção. Ainda mais estranho é que o código no ponto de falha não foi alterado em mais de um ano.

Pergunta

Agora estamos em um ponto em que precisamos começar a explorar outras opções, uma das quais é substituir o ambiente de produção por um novo. É aqui que espero que todos possam me ajudar de alguma forma.

Estou procurando sugestões / recomendações sobre como trocar o antigo ambiente de produção pelo novo com a maior facilidade possível. No entanto, por algum período, preciso que o ambiente antigo e o novo funcionem em conjunto, para validar que o novo ambiente resolve o problema. O novo ambiente seria usado por um conjunto de administradores, enquanto o ambiente antigo seria usado por não administradores. Uma vez que tenhamos feito nossa validação, o ambiente antigo será desativado completamente.

Eu estava pensando em colocar algum tipo de proxy na frente do servidor para que eu pudesse redirecionar as solicitações conforme necessário e estava procurando Aplicativo Load Balancer do Apache Tomcat . Não tenho certeza se essa seria a melhor abordagem, então espero que alguém aqui possa oferecer algumas sugestões.

Suposições

• Apenas os servidores de aplicativos serão trocados
• O servidor de banco de dados permanecerá intacto e, enquanto os dois ambientes de produção estiverem operando em conjunto, eles estarão apontando para o mesmo banco de dados
• Controle completo dos servidores

Tecnologias do servidor de aplicativos

• RHEL 5,7
• Tomcat 6.0

Answer 1

Olhando para o SO pergunta eu não saiba que este é um problema no nível de sistema - A descrição por lá parece um bug de aplicativo. De qualquer maneira, atualizar seu ambiente é sempre algo em que é bom pensar, então vou dar um jeito: -)

Um plano geral de ação para uma grande mudança ou migração de software geralmente se parece com isso (Da sua pergunta SO, em todo lugar eu digo DB / banco de dados você deve estar pensando em seu servidor App2):

1. Duplique seu ambiente da melhor maneira possível em um novo hardware (e, opcionalmente, em um software atualizado - o SO mais recente, o servidor da Web, o DB, etc.)
   Isso pode incluir a clonagem de todos os seus bancos de dados de pré-produção (o que é ótimo se você não tiver dados de teste convenientes).
2. Teste o bejeebus dele para ter certeza de que seu problema desapareceu.
   (Esta parte é problemática no seu caso, já que você disse que não conseguiu reproduzir o problema de forma confiável)
3. Limpar os detritos do seu teste
4. Escolha um horário conveniente para fazer a transição ("conveniente" para seus usuários: Infelizmente, isso geralmente significa 3h em um sábado ou algo igualmente repugnante para a equipe de administração)
5. Fazer a troca - Isso inclui (aproximadamente nesta ordem)
   • Desconectando o ambiente antigo da rede / desativando o acesso do usuário
   • Colocando o ambiente antigo em um estado quiescente para que ele não mude mais
   • Sincronizando quaisquer bancos de dados / dados voláteis para o novo ambiente
   • Fazendo qualquer teste que você possa fazer antes de tornar o novo ambiente ativo
   • Ativando o acesso ao novo ambiente se os testes forem aprovados | (ou estar pronto para colocar o antigo de volta)

No seu caso, dependendo de onde o comportamento desagradável aparece, você pode causar curto-circuito ao redor da etapa 3: se seus administradores forem os únicos que veem a parte mal-comportada do aplicativo, seus administradores podem bater uma cópia de teste do ambiente até que eles reproduzam o bug ou estejam certos de que ele desapareceu (e, se o erro aparecer, você estará de volta no aplicativo). Se o problema é que o usuário está enfrentando, a única solução real é colocar o novo material onde os usuários podem obtê-lo, o que basicamente significa passar por todo o processo.

Você também tem alguns desafios diferentes porque deseja executar seus ambientes em paralelo: Se os dois ambientes estiverem gravando em um banco de dados, será necessário tomar precauções para garantir que ambos os ambientes gravem as mesmas informações em suas cópias. banco de dados (multiplexar as conexões em seu balanceador de carga) ou que ambos os ambientes possam seguramente interagir com um único banco de dados.
Rodar em paralelo praticamente elimina as primeiras e terceiras balas do # 5 acima (você não duplica os back-ends, e o ambiente "antigo" continua rodando - você apenas sustenta o novo próximo a ele).

No seu caso específico com aplicativos idênticos no App1, você pode usar o App2 como um banco de dados compartilhado, mas isso é algo que você precisa considerar do ponto de vista do software (o App2 ficaria louco se visse vários hosts conversando com ele? ).

Não importa o que você faça, definitivamente, fique firme no seu ambiente antigo sem tocá-lo (isso pode ser mais longo ou mais curto, dependendo da sua situação específica - por exemplo, na minha empresa cerca de 8 horas após um grande DB Mudança de esquema acumulamos muitos dados que não podemos reverter: a perda de dados seria catastrófica e a recuperação demorada). Quando tiver certeza de que o novo ambiente resolveu seu problema (ou pelo menos funciona tão bem quanto o antigo ambiente sem nenhum novo problema), você poderá transformar o material antigo em um laboratório de desenvolvimento.