DRBD Madness no ambiente virtual (XEN)

Question

Neste momento estou usando o DRBD para replicar dois diretórios (/ var / www e / var / spool / mail) em dois XEN VPS diferentes e eles estão separados por 7000 milhas! no topo do que estou usando um túnel IPSec transparente VPN para conectar ambos os nós no nível privado, não parece justo eu sei, agora eu estou colocando as pastas (www e mail) no diretório DRBD e eu apenas macio - conecte-os a todas as máquinas, está funcionando e replicando, mas como tenho muita carga no nível da rede (distância e segurança), minha velocidade de leitura / gravação de disco é horrível, abro uma página em 6 minutos e ainda mais, tenho email atrasos e no final do dia, eu enfrento (dual-split-brain) e ambos os nós são reiniciados quando o DRBD traz dois nós como secundários, o processo de montagem nunca acontecerá, o que leva a nenhum documento raiz ativo para o apache iniciar e neste ponto exato, a redundância mata a disponibilidade!

Eu estou tentando liberar a carga na partição DRBD para acelerar um pouco as coisas, então copiei ambos os diretórios de volta ao local original e fiz um link para cada um deles na partição DRBD, mas isso nunca funcionou, agora preciso de boas sugestões! (Estou usando o OCFS2 BTW para a partição DRBD)

    

Answer 1

O que dizer de "não replicar em um link de latência lenta e alta de 7000 milhas para começar".

A replicação em um nível de DRDB tem seu lugar, mas você basicamente a utiliza: ela foi projetada apenas para cenários de baixa largura de banda de baixa latência. Você também pode usá-lo "de forma assíncrona" em um cenário de recuperação de desastre, no qual é aceitável perder alguns dados à medida que a replicação fica para trás e é alcançada.

Se você não estiver em um desses dois cenários, esqueça a ideia de usar algo como o drdb. Organize dados locais nos centros de dados e use replicação e backups para reduzir as coisas de maneira sensata. Por exemplo, faz pouco sentido replicar um spool de email. Web stutff (sites etc.) - também não faz sentido, já que você pode usar outras ferramentas para distribuir esses dados.

Se você usar uma tecnologia de uso especial, ignore as limitações e coloque-a em uma situação na qual ela não é feita, para que você obtenha exatamente o desastre que descreve aqui.

DRDB é uma função de alta disponibilidade para máquinas locais. Permite recolocar um sistema de arquivos no caso de uma máquina falhar. Ele não foi projetado para lidar com cenários de WAN, a menos que você use async e que seja "write out" (ou seja, fazer uma cópia para um local externo). E mesmo assim você ainda precisa ter a largura de banda necessária para lidar com isso - e isso pode ser desgastante (como em: 1gbit +).

    

Answer 2

Como TomTom e ThatGrameGuy apontaram, sua suposição de design (de que você pode conseguir o que você quer com o DRBD) é falha. O DRBD é útil para sincronizar dispositivos de bloco (assim diz o nome: Distributed Replicated Block Device ). Você poderia teoricamente usá-lo em seu cenário atual, como o TomTom descreve (modo Async, para coisas em que não há problema em perder alguns dados), mas você não está descrevendo nada onde essa situação existiria.

Também parece que você está tornando isso muito mais complicado do que precisa ser: Parece que você só precisa de um ambiente "Primário / Secundário" simples.

Para Web Stuff
Sites da Web são alterados periodicamente. É fácil fazer um backup do site que pode ser restaurado em um servidor remoto (ou armazenar tudo em um sistema de controle de versão ou usar um sistema de gerenciamento de configuração para "empurrar" o site para vários servidores).

Para bancos de dados
Os sites da Web geralmente são suportados por banco de dados atualmente (o que geralmente é a única parte que muda "continuamente") - mas todo mecanismo de banco de dados que valha a pena tem algum tipo de capacidade de replicação. Configurada corretamente A replicação de banco de dados é caminho melhor que o DRBD para replicar bancos de dados, porque o mecanismo de banco de dados remoto garante o mesmo nível de ACID que o servidor mestre possui.

Para e-mail
Como a TomTom disse em sua resposta, não há razão para replicar seu spool de correio de saída.
Se você perder o servidor mestre com um ou dois e-mails na fila, seus usuários poderão reenviá-los e, de qualquer maneira, é um caso de canto porque, a menos que o servidor do destinatário esteja inativo, o e-mail está fora do sistema em alguns segundos. Não vale a pena se preocupar.
As caixas de correio das pessoas são outra história: aqui você vai querer backups (ou um sistema de correio que suporte replicação). Isso pode significar que há uma hora ou um dia em que as pessoas não têm acesso ao e-mail antigo quando você faz failover no servidor secundário (enquanto você restaura a mensagem antiga), mas isso geralmente é OK porque eles estão obtendo o e-mails atuais. Se o tempo de restauração não for aceitável, você poderá restaurar continuamente os backups para o servidor secundário (ou usar algo como o rsync para manter as caixas de correio sincronizadas em intervalos de algumas horas).

Há alguns casos de borda no que descrevi acima que você deve estar ciente.

Um, se seus servidores estiverem "muito ocupados", talvez seja necessário balancear a carga adequadamente (usando algo como o HAProxy para distribuir solicitações da Web entre servidores "front-end" e mover correio e banco de dados para seus próprios servidores). É assim que você dimensiona adequadamente.

Techy computer-sciency explanation: the DRBD hackery the bandwidth requirements with DRBD are close to O(N^2) where N = the number of nodes, the solution I've outlined is roughly O(N) where N = the number of DR sites - and the number of DR sites is not likely to exceed 2).

Dois, se seus servidores da Web gravarem dados no sistema de arquivos local, será necessário arquitetar novamente essa solução (armazenar os arquivos no banco de dados ou em um banco de dados NoSQL como o MongoDB ou em um servidor de armazenamento central ou algo semelhante, e possivelmente replicando THIS com o Async DRBD para o local externo para recuperação de desastre em tempo quase real) - basicamente, alguma solução para garantir que as gravações de arquivos locais sejam disponibilizadas para todos os outros servidores "front end" .