Replicação periódica do sistema de arquivos com instantâneo

4

Estou à procura de uma solução de replicação não em tempo real que suporte instantâneos periódicos.

Aqui está minha situação atual:

  • Tenho 2 servidores de email em execução Ubuntu 12.04 LTS
  • O programa do servidor de e-mail que eu uso é o Axigen v8.1.1, servindo 2000+ caixas de correio, com uma taxa de aprox. 2000 e-mails por hora durante as horas de trabalho
  • A configuração é mestre / escravo , usando heartbeat / pacemaker
  • O Axigen usa seu próprio banco de dados proprietário para armazenar todas as configurações e mensagens
  • A maioria dos usuários acessa o servidor de email usando o POP3, mas alguns usam o IMAP4

O que quero implementar:

  • A cada N minutos, deve haver um instantâneo feito no mestre para ser enviado para o Slave
  • O escravo deve conseguir armazenar de forma eficiente pelo menos os M instantâneos mais recentes, além de dois instantâneos diários, caso precisemos reverter
  • (Podemos viver com N minutos de e-mails perdidos; todos os e-mails são armazenados em um sistema de armazenamento MailArchiva)

Meu plano original era implementar o armazenamento de dados do Axigen em um sistema de arquivos ZFS-on-Linux (ZoL), com snapshots regulares que seriam enviados (incrementalmente) para Slave. No entanto, eu fui mordido com a instabilidade de ZoL durante uma sobrecarga de E / S, onde experimentei vários incidentes de CPU Soft Lockup . O grupo de discussão do ZoL sugeriu que eu reduzisse o tamanho do cache do ARC, mas é claro que isso afetaria o desempenho, então, em vez disso, eu reverti para um armazenamento suportado pelo ext4 no Master. (Pode ainda implementar o ZFS no Slave).

Estou pensando em várias opções:

  1. Reconfigure o mestre para que o armazenamento de dados esteja em um armazenamento suportado pelo LVM e crie regularmente um instantâneo do LVM para sincronizar com o escravo usando csync2 ou rsnapshot (e exclua o instantâneo do LVM após uma sincronização bem-sucedida ). No lado Escravo, após cada sincronização bem-sucedida, faça um instantâneo do ZFS para manter o número necessário de instantâneos & instantâneos diários.

  2. Implemente o DRBD em uma configuração Mestre / Escravo, com um armazenamento suportado pelo disco rígido no Master, mas um armazenamento suportado pelo ZVOL no Slave.

  3. Implemente um sistema de arquivos em cluster que suporte instantâneos ... mas qual deles?

Seus pensamentos e sugestões são muito apreciados.

Editar: devido à situação do orçamento do meu departamento, não posso usar uma solução comercial. Talvez no próximo ano, mas infelizmente minha necessidade é atual.

Editar 2: a instabilidade do ZoL pode não ser a instabilidade do próprio ZoL em si, mas eu suspeito mais por causa da inacreditável perda de memória do servidor de email (devido a algumas razões, eu tenho que implementar o Perdition na frente do servidor Axigen, e o Perdition cria um processo por conexão, então a memória do servidor pode estar seriamente fragmentada e bloqueia o ZoL de reivindicar alguns SLABs para aumentar seu Cache ARC)

    
por pepoluan 17.09.2013 / 07:08

1 resposta

2

Bem, pelo menos você pode considerar o uso de lvmsync que é capaz de ler os metadados que o mapeador de dispositivos usa para manter rastrear quais partes do dispositivo de bloco foram alteradas e usar essas informações para enviar apenas esses blocos modificados pela rede. … »

    
por 22.10.2013 / 07:31