.
de plantão Nada estraga um fim de semana como falha no failover, e é por isso que toda sexta-feira Strong The One traz aos leitores uma nova edição de On Call, a coluna em que celebramos os leitores cuja recreação é arruinada por regimes de resiliência podres.
Esta semana, conheça “Brad”, que já trabalhou para uma empresa que fornecia aplicativos de justiça criminal para departamentos de polícia.
Brad estava no suporte e um dos sistemas que ele cuidava era um servidor Data General – na verdade, um par deles, porque um foi configurado para fazer failover para o outro.
“Configurar” pode ser uma descrição muito gentil. O par de caixas compartilhava um IP flutuante – mas o fio que as ligava nunca havia sido conectado. Portanto, embora os servidores tenham sido configurados para failover, eles não foram capazes de fazer isso.
“Esses foram os primeiros dias de failover e nunca haviam sido testados”, explicou Brad. “O princípio estava lá, mas tínhamos muitos testes para fazer antes de realmente entrarmos em operação com failover.”
Justo o suficiente, então.
Enquanto os servidores estavam naquele estado de não exatamente prontidão, Brad estava de plantão e atendeu o inevitável telefonema à 1h com uma reclamação do cliente sobre o desempenho lento.
A primeira tática de Brad foi ficar na cama um pouco – ele não tinha permissão para acessar remotamente esses servidores e esperava que o problema desaparecesse por si só.
Isso não aconteceu. Então ele enfrentou uma viagem de uma hora até seu escritório, de onde o acesso remoto era permitido e possível.
Depois de fazer telnet no servidor, ele descobriu que estava redlining.
“Estava ficando maluco: estourou a CPU, estourou a memória, praticamente travou”, disse Brad ao On Call.
Nenhum problema óbvio foi aparente para explicar a condição do servidor, então Brad acabou reiniciando-o – mesmo quando a polícia que era sua cliente expressou seu descontentamento por não poder fazer pequenas coisas como processar a captura de malfeitores da noite.
Brad trabalhou arduamente durante a noite e até o amanhecer, sem conseguir encontrar uma solução.
Então, um de seus colegas chegou para trabalhar em algo próximo ao horário comercial normal e percebeu que os recursos do servidor eram muito menores do que deveriam.
“Ele verificou o endereço IP físico – não o flutuante que eu estava usando – e viu o que havia acontecido. No dia anterior, desconhecido para o resto de nós, o engenheiro sênior (que não se arrependeu) esteve no local e conectou o cabeamento entre o servidor ativo e o servidor de failover.”
Esta história termina com uma boa notícia e duas más notícias.
O bom foi que o failover funcionou – o servidor ativo teve um problema e o servidor de backup entrou em ação conforme planejado, mesmo que ainda não tivesse sido testado!
A primeira má notícia foi que a caixa de backup tinha menos da metade da memória e da CPU do servidor ativo. “Ele estava fazendo o possível para atender à demanda, mas simplesmente não conseguia lidar”, escreveu Brad.
A segunda era que o failover só funcionava em uma direção: do primário para o backup. As reinicializações de Brad foram aplicadas à caixa de backup, que não desistiu da carga de trabalho e, em vez disso, tentou fazer o trabalho com sua coleção inexplicavelmente insignificante de recursos.
A solução foi fácil. O colega de Brad forçou o IP flutuante de volta ao servidor principal e, de repente, tudo ficou bem.
Mais tarde, Brad e seus amigos removeram o fio que conectava os dois servidores, certificando-se de que o failover não estava funcionando novamente – mesmo que o cliente pensasse que tinha um equipamento resiliente!
“Alguns anos depois, mudamos para os servidores da Sun e, desta vez, testamos o failover antes de entrar no ar”, disse Brad.
O que pode explicar de alguma forma por que a EMC mais tarde adquiriu um Data General atingido por um soma razoável em 1999!
Você já ficou confuso com a tecnologia que funcionou quando não deveria? Em caso afirmativo, clique aqui para enviar um e-mail ao On Call e poderemos compartilhar sua história aqui em uma sexta-feira futura. On Call apareceu sem falhas por anos, mas nossa resiliência não é forte no momento – poderíamos usar muito mais histórias para manter a coluna no seu melhor. ®
.
