DRBD para o HA Server em Small Office Questions

Question

Backround: Precisamos de um servidor de HA em um ambiente de pequeno escritório e estamos olhando para o DRBD para fornecê-lo. Temos apenas cerca de 100 GB que precisam estar no servidor HA e a carga do servidor será extremamente baixa. Os dados provavelmente aumentarão cerca de 10% -25% ao ano se arquivarmos dados antigos do escritório e 50% -75% a cada ano, se não o fizermos.

O ponto é que usamos uma mistura de hardware de nível empresarial e de nível de consumidor que será um problema se não planejarmos preventivamente; e servidores de qualidade pré-construídos FALHAM, portanto, servidores redundantes parecem ser o caminho a percorrer.

O Plano: Estamos pensando que seria bom encontrar (2) os melhores servidores usados para sincronizá-los. Simplesmente precisamos de servidores com capacidade SATA / SAS e espaço para o máximo de unidades que se pode obter pelo preço. Estes servidores parecem que podem ser adquiridos por $ 100- $ 200 (+ algumas partes e unidades adicionais) se você pegar um acordo.

Isso significaria teoricamente que um servidor poderia falhar e se levássemos dias para chegar a ele, contanto que não tivéssemos outra falha por coincidência, as coisas continuariam funcionando até que nosso departamento de TI (eu) pudesse chegar até ele. Nós usaríamos o Debian como um sistema operacional.

Algumas perguntas

1. (A) Como o DRBD controla a falha do inversor ou do controlador? Isso é Isso mostra o DRBD antes do driver de armazenamento, então o que acontece quando o controlador falha e grava dados sujos ou a unidade falha mas não falha imediatamente? Os dados são espelhados para o outro servidor ou não e há risco de corrupção de dados nos servidores em casos como esses?

2. (B) Quais são os pontos de falha do DRBD; teoricamente, enquanto um servidor estiver funcionando, não haverá problemas. Mas sabemos que existem problemas, então quais são os modos de falha usando o DRBD, já que a maioria deles deveria, teoricamente, ser um software?

3. Se quisermos ter dois servidores para isso, seria razoável executar VMs em cada um com MYSQL e Apache para replicação de banco de dados e de servidor web? (Eu estou supondo que sim)

4. O DRBD é confiável o suficiente? Se não, a falta de confiabilidade é isolada para determinadas tarefas ou é mais aleatória. Pesquisando apareceu pessoas com vários problemas, mas esta é a internet com informações aparentemente mais ruins do que boas.

5. Se os dados estão sendo sincronizados pela LAN, o DRBD usa o dobro da largura de banda? Ou seja, devemos duplicar o NICS e fazer alguma agregação e entroncamento de links? Então talvez colocá-los em roteadores separados em circuitos separados e UPS em salas separadas e agora você realmente tem alguma redundância!

6. Isso é muito louco para um escritório em termos de gerenciamento de servidores? Existe uma alternativa mais simples em tempo real (concedido DRBD parece simples na teoria).

Já temos um servidor. Então, parece-me que um segundo servidor USADO com uma unidade dedicada para DRBD poderia facilmente ser adquirido por cerca de US $ 150 a US $ 250 com algumas compras inteligentes. Adicione um segundo roteador, mais drives, mais NICs (Usados) e (2) UPS's e estamos falando de US $ 1.000 +/-. Isso é relativamente barato! E eu estou esperando que isso nos compraria principalmente durante uma falha no servidor. As falhas no drive parecem ser a coisa mais fácil de lidar com o RAID atualmente. São outras falhas de hardware, como controladores, memória ou fontes de alimentação que podem exigir tempo de inatividade para diagnosticar e corrigir, que são a preocupação.

Servidores redundantes para nós, significa que o hardware usado se torna mais viável com mais tempo e mais flexibilidade para eu consertar as coisas quando minha programação permite vs ter que parar tudo para consertar o servidor.

Espero que eu não tenha esquecido que essas perguntas têm respostas fáceis de serem pesquisadas. Fiz uma pesquisa rápida e não encontrei o que procurava.

    

Answer 1

Primeiro, você precisa definir o que você realmente quer dizer com "HA". Com o que você está protegendo, quais são os custos de uma indisponibilidade do tipo X e da duração Y? Como isso afetará sua organização? Qual é o seu papel nesta organização e qual é o seu tempo? Quanto tempo pode gastar com isso? Depois disso, você precisa decidir se esses requisitos permitem esse tipo de solução ou se você precisa de algo diferente.

Segundo: No meu mundo, as frases "Eu preciso de HA" e "Eu vou comprar servidores de baixa qualidade por 200 dólares" não se encaixam (na verdade, para mim, comprar porcaria usada e uso profissional de qualquer tipo não se encaixam em todos).

De qualquer forma, suas perguntas:

1. Se você gravar dados completamente novos no dispositivo de bloco DRBD, ele será gravado corretamente no controlador não quebrado. É uma camada completamente transparente na frente dos discos reais, assim como um software RAID ou LVM. No entanto, se houver corrupção de dados no nó primário devido a controladores quebrados ou erros de leitura do disco, isso poderá se propagar facilmente ao nó secundário, pois as operações de gravação geralmente são ciclos de leitura-modificação-gravação e, nesse caso, um bloco de dados corrompidos serão lidos no nó primário e uma operação de gravação para este bloco será enviada para ambos os nós. Isso traz o ponto mais importante ao usar o DRBD: O mesmo que um RAID, não é de forma alguma um substituto para um backup bom e confiável.

2. Eu não entendo o que você quer dizer aqui.

3. Quando usar VMs em uma configuração de nó único for útil, ela também estará na configuração de dois nós e você terá a vantagem da possível migração ao vivo quando feita corretamente.

4. Na minha experiência, sim. Você deve testá-lo completamente em seu ambiente e passar muito tempo simulando os vários estados de falha que o sistema pode experimentar e aprender e documentar como recuperá-los. Embora seja confiável, o DRBD não é auto-recuperável e requer um bom entendimento da situação para se recuperar de uma condição de falha.

5. Você realmente deseja uma conexão dedicada entre os nós. Em uma configuração de dois nós, isso pode ser uma conexão ponto a ponto sem um comutador ou algo assim. Tudo o mais pode ser tecnicamente possível, mas é um absurdo. Dependendo do seu padrão de uso, usar troncos ou NICs mais rápidos (por exemplo, 10G ethernet ou Infiniband) para esse link dedicado pode ser benéfico, mas se a maioria / todos os dados para ler ou gravar forem provenientes da interface LAN, isso não ajudará você está limitado pela LAN de qualquer maneira.

6. Isso volta ao meu primeiro parágrafo: o que você espera dele e o que você considera HA? Para um administrador de sistemas experiente, pode ser uma maneira barata e confiável de proteger de uma série de falhas, mas requer muita compreensão fundamental de como as peças se encaixam. Muitas pequenas lojas sem uma SA em tempo integral tão experiente são melhores com hardware de qualidade e um bom contrato de suporte.

Finalmente: não tente ajustar retroativamente qualquer solução de HA no seu hardware atual. Conforme escrevi, você precisa da hora de experimentar a configuração e suas condições de falha. Isso requer muito tempo de inatividade e não pode ser razoavelmente feito em seu hardware de produção.