Perguntas sobre ponto único de falha para pequenas operações

Question

1. Se você não puder pagar ou não precisar de um cluster ou servidor sobressalente esperando para ficar on-line no caso de uma falha, parece que você pode dividir os serviços fornecidos por um servidor robusto em dois servidores menos robustos. Assim, se o servidor A cair, os clientes podem perder o acesso a, digamos, e-mail, e se o servidor B cair, eles podem perder o acesso ao sistema ERP .

   Embora a princípio isso pareça ser mais confiável, isso simplesmente não aumenta a chance de falha de hardware? Portanto, qualquer falha não terá um impacto tão grande na produtividade, mas agora você está se preparando para o dobro de falhas.

   Quando digo "menos pesado", o que realmente quero dizer é menor especificação de componente, não qualidade inferior. Portanto, uma especificação de máquina para visualização versus dois servidores é especificada para menos carga cada.

2. Frequentemente, uma SAN é recomendada para que você possa usar o clustering ou a migração para manter os serviços ativados. Mas e a própria SAN? Se eu fosse colocar dinheiro em uma falha, não seria no hardware básico do servidor, teria algo a ver com o armazenamento. Se você não tem algum tipo de SAN redundante, esses servidores redundantes não me dão uma grande sensação de confiança. Pessoalmente, para uma pequena operação, faria mais sentido investir em servidores com componentes redundantes e unidades locais. Eu posso ver um benefício em operações maiores, em que o preço e a flexibilidade de uma SAN são econômicos. Mas para lojas menores, não estou vendo o argumento, pelo menos não para tolerância a falhas.

Answer 1

Tudo isso se resume ao gerenciamento de riscos. Fazer uma análise de custo / risco adequada de seus sistemas de TI ajudará você a descobrir onde gastar o dinheiro e quais riscos você pode ou tem que conviver. Há um custo associado a tudo ... isso inclui HA e tempo de inatividade.

Eu trabalho em um lugar pequeno, então eu entendo essa luta e o geek de TI em mim não quer pontos únicos de falha em qualquer lugar, mas o custo de fazer isso em todos os níveis não é uma opção realista. Mas aqui estão algumas coisas que consegui fazer sem ter um orçamento enorme. Isso nem sempre significa remover o único ponto de falha.

Network Edge : Temos duas conexões de internet, T1 e Comcast Business. Planejando mover nosso firewall para um par de computadores antigos que executam o pfSense usando o CARP para HA.

Rede : A obtenção de alguns switches gerenciados para o núcleo da rede e o uso de ligação para dividir os servidores críticos entre os dois switches impede que uma falha de switch elimine todo o data closet.

Servidores : todos os servidores têm fontes de alimentação redundantes e RAID.

Backup Server : Eu tenho um sistema mais antigo que não é tão poderoso quanto o servidor de arquivos principal, mas tem algumas unidades sata grandes no raid5, que tiram fotos instantâneas do servidor de arquivos principal. Eu tenho scripts de configuração para isso para mudar as funções para ser o servidor de arquivos primário deve ir para baixo.

Servidor de backup externo : semelhante ao backup local, fazemos backups noturnos em um servidor através de um túnel VPN para um dos proprietários.

Máquinas virtuais : Eu tenho um par de servidores físicos que executam vários serviços dentro de máquinas virtuais usando o Xen. Eles estão sendo executados em um compartilhamento NFS no servidor de arquivos principal e eu posso fazer a migração ao vivo entre os servidores físicos, se necessário.

    

Answer 2

Eu acho que esta é uma pergunta com muitas respostas, mas eu concordo que em muitas pequenas lojas a solução de vários servidores funciona e, como você diz, pelo menos alguma coisa continua acontecendo se houver uma falha. Mas isso depende do que falha.

É muito difícil cobrir todas as bases, mas fontes de alimentação redundantes, boa qualidade de energia e bons backups podem ajudar.

Utilizamos o Backup Exec System Recovery para alguns sistemas críticos. Não tanto para backup diário, mas como uma ferramenta de recuperação. Podemos restaurar para hardware diferente, se disponível, e também usamos o software para converter a imagem de backup em uma Máquina Virtual. Se o servidor falhar e precisarmos esperar por reparos de hardware, poderemos iniciar uma VM em um servidor ou estação de trabalho diferente e começar a trabalhar. Não é perfeito, mas pode ser instalado e funcionando rapidamente.

    

Answer 3

Com relação às SANs: quase tudo que você usa será redundante. Mesmo que seja um único gabinete, dentro haverá duas fontes de alimentação, dois conectores e duas cabeças, cada uma com links para todos os discos. Até mesmo algo tão simples quanto um MD3000 vendido pela Dell possui todos esses recursos. As SANs são projetadas para serem o núcleo de suas caixas, então são construídas para sobreviver a qualquer falha de hardware aleatória.

Dito isto, você tem razão de que a redundância nem sempre é a melhor opção. ESPECIALMENTE se aumenta a complexidade. (e vai) Uma pergunta melhor é: "Quanto a empresa aceitará o tempo de inatividade?". Se a perda do seu servidor de email por um dia ou dois não for grande coisa, então você provavelmente não deve se incomodar com dois deles. Mas se uma interrupção do servidor web começar a perder dinheiro real a cada minuto, então talvez você deva gastar o tempo criando um cluster adequado para isso.

    

Answer 4

Quanto mais servidores você tiver, mais chances de algo quebrar, é uma maneira de olhar para ele. Outra é se uma quebra, você está acima do rangido 100%, também como você está dizendo.

A falha de hardware mais comum são os HDs, como você dizia acima. Independentemente de quanto você deseja dividir as operações, você precisa estar RAIDando seu armazenamento.

Eu votaria em alguns servidores (RAIDed, é claro), em vez de em um servidor grande, tanto para a estabilidade das operações quanto para o desempenho. Menos software esbarrando em cada um pedindo recursos, menos lixo, mais discos para serem lidos / gravados, e assim por diante.

    

Answer 5

Eu pessoalmente optaria por vários servidores. Eu não acho que a falha do equipamento seja mais provável neste cenário. Sim, você tem mais equipamentos que podem falhar, mas as chances de qualquer unidade falhar devem ser constantes.

O que ter múltiplos servidores em uma configuração não redundante / não HA me dá a capacidade de descarregar parte do trabalho para outro servidor no caso de uma falha. Então, digamos que meu servidor de impressão fique inativo. Se eu puder mapear algumas impressoras para o servidor de arquivos enquanto estou corrigindo o servidor de impressão, o impacto nas operações será reduzido. E é aí que isso realmente importa. Muitas vezes tendemos a falar sobre redundância de hardware, mas o hardware é apenas uma ferramenta para a continuidade das operações.

    

Answer 6

Eu trabalho em uma pequena loja (um departamento de TI de um homem) e não trocaria meus vários servidores por um único em nenhuma circunstância. Se qualquer um dos servidores ficar inativo, eu tenho a opção de adicionar os serviços que estão faltando a outra máquina ou simplesmente configurá-los em um PC de reserva. Podemos viver com uma interrupção de uma hora ou duas para a maioria das coisas, mas não podemos viver com uma interrupção completa de todos os sistemas. Embora eu possa substituir qualquer um dos nossos servidores com um PC, pelo menos temporariamente, eu não tenho, ou posso me apossar prontamente, de qualquer coisa perto o suficiente para substituir todos os servidores de uma só vez.

    

Answer 7

"Embora no começo isso pareça ser mais confiável, isso simplesmente não aumenta a chance de falha de hardware?"

• Do ponto de vista do hardware, não vejo como isso praticamente aumenta as chances de falha. Existem muitas variáveis aqui, e eu nunca estudei probabilidade, mas simplificarei mais: vamos dizer que a Dell faz 1 servidor ruim a cada 100.000 que eles fazem. Suas chances mudaram de 1 em 100.000 para 2 em 100.000 (ou 1 em 50.000). Então, sim, o dobro da chance, mas ainda por causa da escala, as chances praticamente não são tão diferentes.
• Eu acho que perspectiva é a chave aqui. "Você está se preparando para o dobro de falhas." Talvez da sua perspectiva, mas nos dois cenários que você deu, o e-mail está sendo executado em um servidor e o ERP está sendo executado em um servidor. Portanto, do ponto de vista do email ou erp (que é o que a empresa se preocupa), é realmente o mesmo. A menos que eles se sintam solitários ou como o seu espaço; -)
• Eu acho que você também deveria olhar para isso do ponto de vista das pessoas. Eu acho que o fracasso devido a erros de pessoas é provavelmente mais provável, e desta forma alguém provavelmente iria apenas estragar um servidor de cada vez. Também facilita a identificação de problemas com coisas como carga. Se tanto o email quanto um site forem executados em um servidor, tenha um tempo extra para descobrir onde está o problema.

Nunca é tão simples, servidores grandes e robustos podem ser mais bem feitos ou mal feitos. Eles podem ter peças de maior qualidade, mas talvez façam mais calor e não sejam resfriados adequadamente. Um servidor robusto tem mais RAM, mais CPU's etc, então, no final, talvez você tenha tantos CPUs em ambos os cenários, então talvez um servidor não seja a unidade certa para se pensar.

Por causa da complexidade das chances, o que é mais rentável ganha, eu acho. Se você tiver que pagar pelas licenças 1, um servidor grande pode ser mais barato do que alguns servidores menores, dependendo da estrutura de licenciamento.