Disponibilidade de software durante a atualização?

Question

Imaging Estou executando um servidor de e-mail, por exemplo exim4 (ou um banco de dados, um daemon syslog ...). Agora, ao atualizar este pacote, eu suponho que o aplicativo tenha que ser interrompido ou pelo menos reiniciado após a atualização. Se alguém enviar um email durante esse período, ele falhará. Este caso é considerado durante as atualizações, existem contramedidas tomadas ou é um software que envia e-mails para enviar o e-mail novamente mais tarde?

    

Answer 1

Normalmente, cabe ao software enviar um email para enfileirar até que o serviço esteja disponível. Quando o servidor está inacessível, há várias causas possíveis, o que significa que o envio de software, isto é, a conexão com o servidor, deve ter mecanismos para reconectar e tentar novamente a (s) transação (ões).

Além disso, eu teria que perguntar pela lógica de por que você está atualizando qualquer parte do software do seu sistema se você sabe que não pode reduzir o tempo de inatividade? Você está baixando (?), Descompactando (?) E substituindo executáveis e possivelmente bibliotecas compartilhadas por essa parte específica do software, o que poderia falhar em deixar você com um sistema inutilizável, então se você não puder reduzir o tempo de inatividade, por que está fazendo isso? ?

    

Answer 2

Depende inteiramente das capacidades do software e dos scripts de instalação / atualização do pacote.

Alguns programas continuarão funcionando normalmente durante uma atualização e só precisarão reiniciar quando a atualização estiver concluída .... e, normalmente, os mantenedores de pacotes aproveitam esse fato com seus scripts de empacotamento.

(Eu geralmente relato isso como um bug quando vejo um pacote ser desnecessariamente interrompido durante a atualização, pois isso pode levar a interrupções extremamente longas, por exemplo, um apt-get dist-upgrade se houver muitos pacotes para atualizar ou se um dos pacotes ser atualizado faz uma pergunta no tty Eu também tendem a atualizar os serviços mais importantes individualmente e não como parte de um dist-upgrade para minimizar o tempo de inatividade .... depois de testar o upgrade em máquinas que não são de produção, de couse)

Outros programas não são tão complacentes com a mudança de ambiente enquanto ainda estão em execução e precisam ser interrompidos durante o processo de atualização. Novamente, isso geralmente é tratado automaticamente pelos scripts do package-maintainer.

Em ambos os casos, o trabalho do mantenedor de pacotes é saber o software que eles estão empacotando bem o suficiente para executar a ação mais apropriada.

    

Answer 3

A maioria dos MTAs opera descartando e-mails em um diretório de filas, depois pegando os arquivos na fila e enviando-os quando possível. Durante uma atualização do MTA, o daemon que envia os emails será interrompido por um curto período, mas se um programa cliente enviar um email, ele ainda será enfileirado para processamento quando o daemon for reiniciado.

Na outra direção, se outro servidor tentar entrar em contato com esse servidor e não receber resposta por causa do upgrade em andamento, o outro servidor enfileirará o e-mail e tentará novamente após um breve intervalo. A entrega de emails foi projetada para ser altamente confiável (embora não seja tão confiável quanto costumava ser, em grande parte devido ao peso das contramedidas de spam e spam).

Para outros tipos de software, pode haver um pequeno tempo de inatividade enquanto o daemon está sendo reiniciado. Esse tempo de inatividade geralmente é tratado com várias máquinas servidoras e balanceamento de conexões entre elas. Essa redundância é necessária para sistemas de alta disponibilidade de qualquer maneira (falhas de hardware podem sempre acontecer).

    

Answer 4

Existem softwares que podem ser atualizados sem tempo de inatividade. Portanto, o software deve ser capaz de executar as duas versões - a nova e a antiga - ao mesmo tempo. Durante a atualização, a versão antiga ainda serve os clientes que se conectam a ela. Após a atualização, a nova versão assume o controle e manipula novos clientes. A versão antiga é encerrada depois que o último cliente se desconecta dela e depois pode ser removida (ou permanecer em segundo plano como modo de fallback se a nova versão não funcionar corretamente e houver mecanismos para degradação gradual implementada). Mas esses mecanismos são implementados em poucos casos de uso.

Caso contrário, jordanm está certo com seu comentário sobre redundância.