Depois de ter um pouco de medo de um servidor que não iria aparecer uma manhã, os altos decidiram que a empresa precisa de uma alta disponibilidade / configuração de failover.
Temos 5 servidores principais (4x Linux, 1x OpenBSD), todos os quais precisam estar em execução para a empresa operar. Três dos servidores são bastante padrão (Arquivos / Web / Banco de Dados), o quarto lida com a maioria dos roteadores de rede e proxies da Web, enquanto o quinto suporta nosso sistema telefônico e possui hardware não padrão.
Meu chefe afirmou que o tempo de resposta para uma falha no servidor deve ser inferior a 30 minutos.
Minha experiência neste campo é inexistente (sou apenas um programador que foi 'promovido'), então acho que minha pergunta se resume a:
- Isso é algo que deve ser tentado por alguém com habilidades médias de administrador de servidor. Se sim, o que devo ler e com quem devo falar?
Obrigado.
Respostas:
Eu acho que você deve começar reunindo números para descrever o custo associado ao cumprimento do "requisito" declarado para ver se ele está dentro do orçamento. Se você não se sentir confortável com todos os métodos "normais" que seriam usados para atender ao requisito (clustering de failover, hipervisores com capacidade de "migração a quente" etc.), provavelmente faria bem em encontrar um consultor que possa ajudar.
Haverá algum custo associado ao estudo de viabilidade, mas custará muito menos descobrir que uma boa solução não se encaixa dentro do requisito declarado (o que significa que as expectativas precisam ser definidas de maneira mais realista pela gerência - ou elas é necessário desembolsar mais dinheiro) do que custará fazer algo sem sentido, que acaba não cumprindo o requisito e gastando uma tonelada de dinheiro no processo.
Parece que seu chefe acabou de tirar esse número do ar. Talvez ele tenha feito alguma análise e saiba qual é o custo por hora associado ao tempo de inatividade de vários sistemas, mas duvido. Parece um número torto no céu que não está ligado à realidade. Eu ficaria surpreso se todos os seus sistemas precisassem desse tipo de disponibilidade. Pode ser que, durante o estudo dos negócios, você descubra que apenas um subconjunto de funcionalidades precisa ter esse grau de tempo de atividade e tolerância a falhas (e, portanto, essa solução acabaria por custar menos). Tenho certeza de que os telefones e o aplicativo de linha de negócios estão lá em cima, mas você pode ter alguma tolerância ao tempo de inatividade em alguns dos outros sistemas.
Meu instinto diz que você provavelmente encontrará uma vitória no uso de tecnologias de virtualização para criar um sistema de failover baseado na migração de máquinas virtuais entre hardware redundante. Se caberá ou não no seu orçamento, dependerá do seu negócio, pois você definitivamente precisará de algum tipo de SAN para fazer esse trabalho efetivamente.
Não desconsidere o cluster de failover "tradicional". Definitivamente, existem "vitórias" também se seus aplicativos forem adequados para essa configuração.
Gostaria de saber se o seu chefe pensou em cenários de falhas catastróficas (queimaduras em edifícios, inundações, tornados, roubos, etc.). Se isso ainda não estiver planejado, seria uma oportunidade de ouro para trabalhar em algum planejamento geral de continuidade de negócios e contingência de recuperação de desastres.
Obtenha ajuda de alguém que possa entrar e estudar sua empresa e fazer recomendações. Você não vai se arrepender.
fonte
"Este caminho leva a muita dor e mágoa ..."
Então, qual é o plano de continuidade de negócios? Seu plano de recuperação de desastres?
Você já discutiu isso? Escreveu isso? TESTADO?
Você precisa ter uma conversa adequada com os "superiores" e realmente entender os requisitos de alta disponibilidade, pois é diferente para diferentes serviços.
Então, qual foi realmente o "ponto de dor" que eles sentiram naquela manhã?
Foi isso?
Presumo que você comprou hardware de alta qualidade para seus principais sistemas? Bom, porque o preço baixo do hardware é uma economia falsa, pois esses servidores vêm com tudo "duplo" na caixa.
Também assumirei que você sabe COMO reconstruir um servidor, trocar ventiladores, fontes de alimentação, rack de um servidor, configurar redes de caminho duplo em switches redundantes? Você já fez isso o suficiente para entender o que funciona e o que não funciona, o que é normal e o que é errôneo? Caso contrário, obtenha ajuda e treinamento (ou pelo menos prática e experiência).
Talvez grande parte do problema tenha sido MEDO. Eles não tinham idéia de que um problema desse tipo poderia acontecer (e qual a importância dos servidores para os negócios deles) e você realmente não sabia o que estava fazendo (?) Um problema de confiança?
Você precisa obter todas as informações acima antes de seguir a rota de alta disponibilidade, muito cara. A empresa pode comprar esse equipamento caro (e a maior parte, por definição, só será usada em caso de falha e muitas vezes nunca usada!)
fonte
Evan acertou em alguns pontos positivos, mas aqui estão, talvez, algumas maneiras específicas de baixo custo para obter um tempo de recuperação de menos de 1 hora diante de falhas.
Provavelmente, pequenas empresas significam hardware pequeno; portanto, pode não ser muito caro fazer algumas coisas simples que realmente adicionam uma quantidade significativa de resiliência diante dos problemas. A idéia principal é apenas ter hardware extra pronto para uso.
Primeiro, fique à vontade com o pensamento de um IP virtual. Esse é o endereço IP com o qual os usuários falarão, mas podem residir em qualquer servidor que você fornecer. Este é o endereço IP com o qual você é usuário, e os aplicativos vão querer conversar. E será a mais útil para qualquer solução que você escolha. Ter um VIP significa que você não precisa reconfigurar nenhum dos aplicativos ao realizar o failover. Além disso, lembre-se de que ter hardware redundante também tem o impacto de aumentar a sobrecarga da administração, fazendo duas atualizações de configuração em vez de 1.
Se começarmos com o seu servidor de roteamento / proxy da Web, é provavelmente o mais fácil, pois não haverá nenhum estado real que precise ser armazenado na própria caixa. Portanto, basta obter uma duplicata da mesma caixa e configurá-la da mesma forma. Eu manteria os dois conectados ao segmento da LAN e, assumindo que sua Internet está em outra interface, troque os cabos se houver falha. De uma perspectiva de roteamento, você define todos os clientes LAN para direcionar o endereço .1 (o VIP) para o servidor proxy e de rota padrão, fornece ao servidor A o endereço .2 e o servidor B o endereço .3. Dessa forma, ambos podem ser gerenciados para atualizações de configuração (aplica-se a ambos). E tudo o que você precisa fazer para realizar o failover é remover a atribuição de IP .1 de .2 e movê-la para .3 e mover a conexão com a Internet para a outra interface. Não é muito complicado, fácil de fazer e entender, e custa o hardware extra de uma segunda caixa. Se você puder obter redundância no lado da Internet, poderá adicionar um pouco de complexidade e obter failover automático usando algo como VRRP.
Sem detalhes, é difícil dizer, mas seu servidor da Web pode ser igualmente simples. Adicione um segundo servidor com configuração idêntica, crie um vIP entre os dois e mova o VIP para o backup em caso de falha. Geralmente, não me importo se o estado da sessão for perdido em um failover (é um problema crítico causar um failover). Portanto, se os usuários tiverem que efetuar login novamente, não é grande coisa. Novamente, o vrrp provavelmente pode ser usado para failover automático.
Passando para o seu banco de dados, isso é significativamente mais complexo. A maioria dos bancos de dados possui algum tipo de modelo primário / secundário, no qual você faz backup do banco de dados original no secundário e copia todos os logs de transações ou alterações no banco de dados. Novamente, você pode combinar isso com VIPs para os aplicativos / usuários que realmente acessam o banco de dados. No entanto, o failover é mais complicado. Dependendo da falha do primário, talvez seja necessário colocar as unidades em funcionamento para copiar e restar os logs de transações. Então traga o secundário ativo. Se você puder tolerar alguns dados perdidos, poderá trazer o ativo secundário imediatamente. Após o failover, o servidor B agora é o principal, e você deve restaurar o servidor A e transformá-lo no novo backup, para que fique pronto quando o servidor b tiver problemas.
Servidores de arquivos são sempre a parte mais difícil, pois, diferentemente dos DBs, é muito mais difícil obter um recurso interno do sistema de arquivos. No entanto, é possível obter algum nível de resiliência com um segundo servidor, e escrever um script simples que varre o sistema de arquivos em busca de alterações e copiar quaisquer novos arquivos para o seu secundário. Basicamente, você pode executar o rsync em um cron que acredito fazer isso. Mais uma vez, você usa um VIP que você dá aos usuários e passa a fazer parte de um failover. No seu script, recomendo vivamente que você verifique se o sistema é o proprietário do VIP antes de transferir arquivos. Você realmente não quer que o rsync execute na direção errada e substitua as alterações que os usuários estão fazendo. Isso pode perder alguns arquivos se houver uma falha,
Eu não tenho idéia do que você poderia fazer sobre o seu sistema telefônico ... isso realmente depende do fornecedor e de como ele está configurado. O fornecedor pode ter alguma solução pronta para resiliência.
Algumas palavras finais de aviso. Certifique-se de testar completamente qualquer configuração com a qual você vá. Certifique-se de saber como fazer o failover sem perder essas informações críticas. Teste teste de teste para garantir que funcione quando você precisar. Verifique se você possui processos em vigor para que as alterações de configuração, atualizações de software, etc. sejam aplicadas corretamente ao primário e aos backups. A boa notícia é que você provavelmente pode executar failover controlado quando quiser trazer um servidor para atualização, etc. Não é uma configuração ativo-ativo, portanto, você não tem idéia se o secundário funcionará quando você precisar.
Eu trabalho em telecomunicações e nosso equipamento é altamente redundante, incluindo na maioria dos casos redundância geográfica. Nosso ponto de falha número 1 é a redundância não é testada após as alterações, e os usuários fazem alterações que não sabem como o modelo de redundância funciona. No entanto, temos o problema adicional de que todos os nossos equipamentos precisam suportar failover automático em não mais que alguns segundos. Você pode tolerar a intervenção manual em seus failovers, se precisar estar em funcionamento em 30 a 60 minutos. Você só precisa estar preparado. Boa sorte.
fonte
Todos os outros pontos são ótimos, então apenas alguns comentários.
É impossível garantir 30 minutos, especialmente para tudo. Você pode dizer que é um alvo, mas não há como garantir, porque sempre há o fator X. Você poderia ter duas linhas de ISP e um caminhão colidir com o prédio e eliminá-los, porque você não achou que importava tê-los roteados de lados opostos do edifício.
Para começar a custar, dobre tudo. Você tem 5 servidores e precisa dobrar isso. Nem tudo precisa estar em hardware, você pode virtualizar, mas entende o que quero dizer. Além disso, tudo deve estar ciente de alta disponibilidade, o que também aumentará o custo, você pode descobrir que precisará substituir seu roteador por um novo e, oh, você precisará de dois deles. Não se esqueça de dobrar a alimentação e obter o gerador, porque você não pode garantir que a companhia de energia retornará em 30 minutos.
Esses exemplos estão pensando que é mais ou menos uma configuração de espera quente, que é o que suspeito que seu chefe esteja pensando.
O que acho melhor para as pequenas empresas é projetar um plano para recuperar e classificar tudo.
Descobrir quais serviços são
crítico (paradas de negócios)
importante (os negócios diminuem)
rotineira (as empresas podem se contentar com isso por um tempo).
Por exemplo, os telefones da sua central de atendimento são críticos, então talvez valha a pena comprar um segundo servidor e um segundo ISP e a sua falta de energia média é de cerca de 15 minutos, portanto, teremos um no-break por 60 minutos (não esqueça as estações de trabalho também). Agora vamos dizer que o ERP é importante apenas, o que significa que você pode funcionar sem ele por um tempo. Talvez o pessoal da sua central de atendimento o use, mas, se estiver desativado, poderá voltar a caneta e papel ou bloco de notas e atualizar o ERP depois. O procedimento para fazer isso, se estiver inativo, pode ser mais barato do que tentar torná-lo um serviço crítico. E os rotineiros podem ser algo como impressoras, ok, é uma dor, mas podemos esperar alguns dias, se todos caírem.
Isso também dá a você a ordem de consertar coisas se a merda realmente atingir o ventilador um dia :)
fonte
É possível? Certo. É acessível? Provavelmente não é para uma "pequena empresa", especialmente se você tem um chefe que fornece números arbitrários para trabalhar, e ele está exigindo alta disponibilidade de um departamento de TI que consiste em um programador substituto (visto muitas vezes em outros lugares e nunca bonito para os seus níveis de estresse, se a sua situação era como a deles).
O failover é possível, mas geralmente requer hardware redundante, SANs para compartilhar dados entre servidores, etc ... em outras palavras, boa sorte em financiar se eles não contratarem um administrador dedicado para cuidar dele.
O hardware do seu sistema de chamada que você mencionou é um hardware especializado e você aludiu a ser um callcenter. Você deve conversar com o fornecedor sobre opções para tornar isso redundante. Brincar com isso pode anular o apoio em primeiro lugar.
Em outros sistemas, você provavelmente poderia obter alguma redundância investindo em soluções do tipo VMWare (ou Hyper-V ou XenServer, mas eu examinaria o VMware e o XenServer primeiro). Em seguida, você pode obter uma SAN, alguns servidores robustos com comutadores de rede rápidos e usar o LiveMotion para migrar servidores virtualizados entre servidores de hardware, se houver uma falha, além de equilibrar parte da carga entre os servidores conforme as necessidades.
Você mencionou que está executando o Linux nesses sistemas. Com dinheiro para obter vários servidores, você pode configurar o DRBD com um programa de pulsação e o STONITH para replicar dados entre servidores e assumir o controle quando um deles estiver indisponível; você gostaria de configurar um sistema no qual duplicou literalmente cada servidor, além de duplicar o consumo de energia e a dissipação de calor na sala do servidor (se você tiver uma sala do servidor). Isso pode ser feito pelo custo do hardware e pela sua sanidade. Além disso, você teria que testá-lo, teria tempo de inatividade durante a configuração e ainda terá a possibilidade de que não funcione às vezes, pois ainda há a possibilidade de surgir problemas que precisam ser resolvidos (divisão cérebro, por exemplo).
O último é um plano para fazer com que alguns sistemas atuem como sistemas em branco e tenha um plano de backup realmente bom para permitir a restauração de dados em um dos sistemas "em branco" se um servidor morrer. Ter hardware no local oferece algumas opções se / quando um servidor morrer; mas você ainda terá algum tempo de inatividade ao restaurar dados e precisará de instruções sobre como instalar corretamente seus aplicativos no novo servidor. Dependendo da rapidez com que você trabalha e do tamanho dos dados, você pode ter um tempo de inatividade de algumas horas a um ou dois dias. Você não tem um trabalho, em bom estado de backup para os seus servidores, com um plano de recuperação no lugar, né?
Você deveria tentar? Minha primeira reação é que, se você está coçando a cabeça com alguma das sugestões ou sentindo uma pontada no estômago ao tentar pensar nessas coisas, não deve. Você precisaria de uma empresa de consultoria para analisar o problema, calcular os custos e implementá-lo ou contratar um administrador de sistemas dedicado para fazer isso em sua empresa.
O fato de que eles estão dizendo para você fazer isso e você está dizendo que você é "apenas um programador que foi" promovido "e que você tem um PHB pedindo para redundância com um tempo máximo de falha de 30 minutos é que você é gentil de um riacho.
fonte