técnica de reinício rápido em vez de manter o estado bom (disponibilidade e consistência)

Question

Quantas vezes você resolver seus problemas de reiniciar um computador, roteador, programa navegador? Ou mesmo por reinstalar o componente do sistema operacional ou software?

Este parece ser um padrão comum quando há uma suspeita que o componente software não manter o seu estado no caminho certo, então você é só pegar o estado inicial, reiniciando o componente.

Eu ouvi que a Amazon / Google tem um conjunto de muitos-muitos nós. E uma importante propriedade de cada nó é que ele pode reiniciar em segundos. Assim, se um deles falhar, então devolvê-lo de volta ao estado inicial é apenas uma questão de reiniciá-lo.

Existem quaisquer linguagens / frameworks / padrões de design lá fora, que aproveitam esta techinque como um cidadão de primeira classe?

Editar O link que descreve alguns princípios por trás da Amazon, bem como os princípios gerais de disponibilidade e consistência: http://www.infoq.com/presentations/availability-consistency

Answer 1

Isso é comum no mundo de sistemas embarcados e em telecomunicações. É muito menos comum no mundo com base no servidor.

Há um grupo de pesquisa que você pode estar interessado em. Eles têm trabalhado em Recuperação-Oriented Computing ou "ROC". O princípio fundamental na ROC é que o, melhor, estado mais confiável mais limpo que qualquer programa pode ser em é logo após o arranque. Portanto, ao detectar uma falha, eles preferem para reiniciar o software em vez de tentativa de recuperar da falha.

Parece bastante simples, certo? Bem, a maioria das pesquisas tem ido para implementar essa idéia. A razão é exatamente o que você e outros comentadores têm fora pontas:. OS reiniciado são muito lento para ser um método de recuperação viável

ROC se baseia em três partes principais:

1. Um método para detectar falhas o mais cedo possível.
2. Um meio de isolar o componente defeituoso, preservando o resto do sistema.
3. em nível de componente reiniciado.

A principal diferença real entre ROC e a abordagem típica "restart noturno" é que ROC é uma estratégia onde as reinicializações são uma reação. O que quero dizer é que a maioria software é escrito com algum grau de tratamento de erros e recuperação (reposição e-captura, extração de madeira, laços de repetição, etc.) Um programa de ROC seria detectar a falha (exceção) e imediatamente exit. Mistura-se os dois paradigmas apenas deixa-o com o pior dos dois mundos: --- baixa confiabilidade e erros.

Answer 2

Esta é realmente muito raro no / mundo linux unix. Desses sistemas foram projetados (e assim foi windows) para se proteger de processos mal comportados. Estou certo de que o Google não está contando com reiniciado rígidos para software misbehaved correta. Eu diria que esta técnica não deve ser empregado e se alguém diz que a rota fatest para a recuperação de seu software você deve olhar para outra coisa!

Answer 3

microcontroladores têm tipicamente um watchdog timer, que deve ser redefinido (por uma linha de código) de vez em quando, ou então o microcontrolador irá repor. Isso mantém o firmware de ficar preso em um loop infinito, espera preso para a entrada, etc.

memória não utilizada às vezes é definida como uma instrução que provoca um reset, ou um salto para um mesmo local que o microcontrolador começa em quando é reiniciado. Isso irá redefinir o microcontrolador se de alguma forma vai para um local fora da memória do programa.

Answer 4

Sistemas embarcados pode ter uma característica checkpoint onde cada n ms, a pilha atual é salva. A memória é não volátil na reinicialização de energia (isto é alimentada por bateria), assim por diante um começo de energia, um teste é feito para ver se as necessidades de código para saltar para um ponto de verificação de idade, ou se é um sistema novo.

Estou indo para adivinhar que uma técnica semelhante (mas mais sofisticado) é usado para Amazon / Google.

Answer 5

Embora eu não consigo pensar em um padrão de design per se, na minha experiência, é um resultado de "escolha está quebrado" de desenvolvedores.

Eu vi um site aleijado 50 usuários tanto SQL Server Enterprise Edition (com um banco de dados de 750 MB) e um servidor Novell por causa de gerenciamento de conexão pobre juntamente com chamadas excessivas e nenhum cache. Novell era sempre o culpado de acordo com os desenvolvedores até encontrarmos uma chamada faltando "CloseConnection" em uma biblioteca central. Até então, milhares foram gastos, sem sucesso, em upgrades para o endereço que uma linha de código em falta.

(Por que eles tinham Enterprise Edition foi além de mim por isso não pedir !!)

Answer 6

Se você olhar para linguagens de scripting como PHP em execução no Apache, cada invocação inicia um novo processo. No caso básico não há como estado compartilhado entre processos e uma vez que a invocação tiver terminado o processo é encerrado.

As vantagens são menos ônus sobre gestão de recursos como eles serão liberados quando o processo acabamentos e menos necessidade de tratamento de erros como o processo está concebido para deixar-rápido e não pode ser deixado em um estado inconsistente.

Answer 7

Eu vi que alguns lugares no nível do aplicativo (um aplicativo reiniciar-se se as bombas).

Eu tenho implementado o padrão em nível de aplicação, onde uma leitura serviço de Dbase arquivos começa a receber erros depois de ler x quantidade de vezes. Ele procura por um erro específico que é jogado, e se vê que o erro, o serviço chama um aplicativo de console que mata o processo e reinicia o serviço. É de kludgey, e eu odeio isso, mas para esta situação particular, eu poderia encontrar nenhuma resposta melhor.

E tenha em mente que o IIS foi construído em um recurso que reiniciar o pool de aplicativos sob certas condições.

Para essa matéria, reiniciar um serviço é uma opção para qualquer serviço no Windows como uma das ações a tomar quando o serviço falhar.