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

1. Se você não puder pagar ou não precisar de um cluster ou servidor sobressalente aguardando para ficar on-line em caso de falha, parece que você pode dividir os serviços fornecidos por um servidor robusto em dois servidores menos robustos. Portanto, se o Servidor A for desativado, os clientes poderão perder o acesso, digamos, por email, e se o Servidor B for desativado, eles poderão perder o acesso ao sistema ERP .

   Embora a princípio isso pareça 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 robusto", o que realmente quero dizer é a especificação de componentes mais baixa, não a qualidade inferior. Portanto, uma especificação de máquina disponível para visualização versus dois servidores especificados para menos carga cada.

2. Muitas vezes, uma SAN é recomendada para que você possa usar o armazenamento em cluster ou a migração para manter os serviços ativos. Mas e a própria SAN? Se eu colocasse dinheiro onde uma falha ocorrerá, ela não estará no hardware básico do servidor, terá algo a ver com o armazenamento. Se você não tiver algum tipo de SAN redundante, esses servidores redundantes não me darã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. Vejo um benefício em operações maiores, nas quais 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.

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 local pequeno, para entender essa luta e o nerd de TI em mim não deseja nenhum ponto de falha em nenhum 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 pude fazer sem um orçamento enorme. Isso nem sempre significa remover o ponto único de falha.

Borda da rede : Temos 2 conexões de Internet T1 e Comcast Business. Planejando mudar nosso firewall para um par de computadores antigos executando o pfSense usando o CARP for HA.

Rede : obter alguns comutadores gerenciados para o núcleo da rede e usar a ligação para dividir os servidores críticos entre os dois comutadores evita que uma falha do comutador destrua todo o armário de dados.

Servidores : todos os servidores possuem fontes de alimentação redundantes e RAID.

Servidor de backup : Eu tenho um sistema mais antigo que não é tão poderoso quanto o servidor de arquivos principal, mas possui algumas unidades sata grandes no raid5, que tiram instantâneos de hora em hora do servidor de arquivos principal. Eu tenho scripts configurados para que isso mude de função para ser o servidor de arquivos principal, caso ele caia.

Servidor de backup externo : semelhante ao backup no local, fazemos backups noturnos em um servidor em um túnel VPN para uma das casas 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 executando 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.

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

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

Usamos 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 um 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 pelos reparos de hardware, podemos iniciar uma VM em um servidor ou estação de trabalho diferente e seguir adiante. Não é perfeito, mas pode ser instalado e funcionando rapidamente.

Em relação às SANs: quase tudo que você usar será redundante. Mesmo que seja um gabinete único, no interior haverá fontes de alimentação duplas, conectores duplos e 'cabeças' duplas, cada uma com links para todos os discos. Mesmo algo tão simples como um MD3000 vendido pela Dell tem todos esses recursos. As SANs foram projetadas para serem o núcleo de suas caixas, para que sejam construídas para sobreviver a qualquer falha aleatória de hardware.

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

Quanto mais servidores você tiver, mais chances de algo quebrar, é uma maneira de ver isso. Outra é que, se alguém quebra, você aumenta 100%, também como está dizendo.

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

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

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

O que ter vários servidores em uma configuração não-redundante / não-HA me dá é a capacidade de descarregar parte do trabalho para outro servidor em caso de falha. Então, digamos que meu servidor de impressão fique inoperante. Se eu conseguir mapear algumas impressoras para o servidor de arquivos enquanto estou corrigindo o servidor de impressão, o impacto nas operações será menor. E é aí que realmente importa. Costumamos falar sobre redundância de hardware, mas o hardware é apenas uma ferramenta para a continuidade das operações.

Eu trabalho em uma pequena loja (departamento de TI de um homem) e não trocaria meus múltiplos servidores por um único em nenhuma circunstância. Se qualquer um dos servidores ficar inoperante, tenho a opção de adicionar os serviços que estão faltando a outra máquina ou simplesmente configurá-los em um PC sobressalente. Podemos viver com uma interrupção de uma ou duas horas 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 de nossos servidores por um PC, pelo menos temporariamente, eu não tenho, ou posso me apossar rapidamente de algo em qualquer lugar perto de poderoso o suficiente para substituir todos os servidores de uma só vez.

Sua postagem original supõe que você não pode pagar por um cluster, mas considera soluções com dois servidores (sem incluir backups). Isso implicaria que você provavelmente tem três servidores em mãos, o suficiente para iniciar um cluster.

Existem soluções intermediárias que podem evitar o SPoF e ainda serem apropriadas em empresas de pequeno / médio porte: replicação nó a nó sem armazenamento SAN.

Isso é suportado, por exemplo, pelo Proxmox (mas acho que também é suportado pelo XCP-ng / XenServer e provavelmente pelo ESXi).

Vamos considerar uma configuração de 3 nós. Tudo com RAID, PSU redundante, rede redundante.

• Os nós A e B têm CPU robusta e muita RAM.
• O nó C é mais modesto na CPU / RAM, mas possui muito armazenamento e é usado para fornecer quorum ao watchdog de alta disponibilidade e aos backups do host.

Então duas opções:

1. Todas as VMs normalmente são executadas no nó A e são replicadas no nó B (exigindo sepcs de CPU decentes)
2. As VMs são divididas entre o nó A e B e replicadas mutuamente algumas do nó A para o nó B e do nó B para o nó A.

Esse tipo de configuração pode tolerar uma falha na rede, uma falha total e principal do nó (qualquer uma das três), com um tempo de inatividade de cerca de 1 minutos (aproximadamente o tempo necessário para a inicialização da VM). A desvantagem é a perda de dados desde a última replicação (que, dependendo das configurações e do desempenho do hardware, pode ser tão baixa quanto 1 minuto e até algumas horas).

Com a segunda opção (VM normalmente dividida entre os nós A e B), você deve priorizar qual VM pode voltar a ficar online. Como a carga da sua VM geralmente é dividida entre dois servidores, a execução de todos eles em um único nó pode esgotar a RAM do nó ou congestionar a CPU.

"Embora a princípio isso pareça 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 simplifique demais: digamos que a Dell faça 1 servidor ruim por cada 100.000 que ele faz. Suas chances mudaram de 1 em 100.000 para 2 em 100.000 (ou 1 em 50.000). Então, sim, duas vezes a chance, mas ainda por causa da escala, as chances praticamente não são tão diferentes.
• Eu acho que a perspectiva é a chave aqui. "Você está se preparando para o dobro de falhas." Talvez da sua perspectiva, mas nos dois cenários que você forneceu, o email está sendo executado em um servidor e o ERP está sendo executado em um servidor. Portanto, da perspectiva do e-mail ou erp (que é a preocupação da empresa), é realmente o mesmo. A menos que eles se sintam solitários ou gostem de seu espaço ;-)
• Eu acho que você também deveria olhar para isso do ponto de vista das pessoas. Eu acho que falha devido a erros de pessoas é provavelmente mais provável, e dessa maneira alguém provavelmente estragaria um servidor de cada vez. Também facilita a identificação de problemas com coisas como carga. Se o email e o site forem executados em um servidor, haverá um tempo extra para descobrir onde está o problema.

Nunca é tão simples assim, grandes servidores robustos podem ser melhor criados ou piores. Eles podem ter peças de qualidade superior, mas talvez aqueçam mais e não sejam resfriados adequadamente. Um servidor robusto tem mais memória RAM, mais CPUs, etc., portanto, no final, talvez você tenha o mesmo número de CPUs nos dois cenários, então talvez um servidor não seja a unidade certa para se pensar.

Devido à complexidade das chances, o que for mais rentável, eu acho. Se você tiver que pagar pelas licenças, um servidor grande poderá ser mais barato do que alguns servidores menores, dependendo da estrutura de licenciamento.

Minha abordagem padrão é evitar qualquer infraestrutura centralizada. Por exemplo, isso significa que não há SAN , nem Load Balancer . Você também pode chamar essa abordagem centralizada de "monolítica".

Como arquiteto de software, estou trabalhando com a infraestrutura do cliente. Isso pode significar usar seu próprio datacenter particular ou usar algo como a AWS. Portanto, normalmente não tenho controle sobre se eles usam uma SAN ou não. Como meu software geralmente abrange vários clientes, eu o construo como se fosse executado em máquinas individuais e isoladas em uma rede.

O exemplo de email

O email é estranho, porque é um sistema legado (que funciona). Se o email fosse inventado hoje, provavelmente usaria APIs RESTFul em servidores Web, e os dados estariam em um banco de dados que poderia ser replicado usando ferramentas normais (replicação transacional, backups incrementais).

A solução da arquitetura de software é que um aplicativo Web se conecte a um de uma lista de nós disponíveis (aleatoriamente) e, se não estiver disponível, tentará se conectar a outro nó (aleatoriamente). Um cliente pode ser expulso de um servidor, se estiver muito ocupado. Aqui, não há necessidade de um balanceador de carga se conectar a um web farm; e, não há necessidade de uma SAN para alta disponibilidade. Também é possível fragmentar o banco de dados por departamento ou região.

Commodity significa ...

Portanto, em vez de ter um ou dois servidores caros e uma SAN com medidas de redundância interna, você pode usar várias máquinas de baixo custo e baixo consumo de energia.

• Simplicidade - a redundância vem puramente do número de dispositivos. Você pode verificar facilmente sua redundância pela quantidade de máquinas. E você estima mais corretamente que eles têm uma chance maior de falhar e se prepara para isso.

• Porcentagem de redundância - Se você possui 2 servidores, se um falhar, resta 1 (50%). Se você possui 10 servidores de commodities e um falha, você tem 9 (90%) restantes

• Inventário - um dispositivo de commodity está prontamente disponível em qualquer loja próxima por um ótimo preço.

• Compatibilidade - com canais de fibra e todos os tipos de padrões para formatos de volume de disco, dispositivos básicos e arquitetura de software significa que você não está preso a um único modelo ou marca de dispositivo.

• Desempenho - com 2 dispositivos na SAN, eles precisam estar na mesma sala. Com a abordagem de máquina de commodity, se você tiver 5 escritórios, poderá ter 2 em cada escritório, com redundância de WAN VPN entre escritórios. Isso significa que o software e as comunicações estão na LAN no tempo de acesso <1ms.

• Segurança - com base no alto nível de redundância, você pode facilmente reconstruir nós como um processo regular de mercadoria. Deseja reconstruir um cluster monolítico de 2 servidores? Saia do manual. Com a reconstrução de máquinas com freqüência (com automação), você mantém o software atualizado e evita que hackers ou vírus consigam uma posição na rede.

Nota: Você ainda precisará ter várias redundâncias de roteador de comutador e gateway