Como migrar dados do servidor para o servidor com o menor tempo de inatividade possível?

Question

Eu tenho um servidor executando o dovecot usando o formato maildir com uma base de usuários bastante grande (10k usuários ou mais) com cada usuário tendo em torno de uma cota de GB.

Os diretórios de e-mail reais são armazenados em um sistema de armazenamento separado que nosso servidor de e-mail monta via NFS.

Devido a problemas de desempenho em nosso sistema de armazenamento, estamos atualizando para um novo sistema de armazenamento. Estamos transferindo dados do sistema antigo para o novo sistema diretamente, mas esse processo ainda demora bastante (16 horas).

Nosso plano é executar rsyncs de volta para trás, depois que o segundo terminar, derrubar imediatamente o dovecot / qmail / etc no servidor de e-mail, alternar os locais de montagem para o novo sistema e trazer o backup de e-mail. Isso só somaria um minuto ou dois para o tempo de inatividade com sorte. O problema é que qualquer e-mail recebido enquanto o último rsync estava sendo executado ainda não será copiado. Então, para aliviar isso, após o switch nós rsync novamente sem o sinalizador --delete que normalmente usamos. Existem alguns problemas com isso, mas o maior da minha perspectiva é que os usuários não têm acesso ao e-mail que eles APENAS tinham antes da troca.

Alguém tem uma sugestão sobre como fazer isso com um tempo de inatividade muito pequeno e não perdendo os dados por qualquer período de tempo? O antigo sistema de armazenamento é um NetApp, o novo sistema é apenas uma caixa freebsd com um grande san conectado, e o servidor de e-mail é o Ubuntu.

Parece-me que deve haver uma maneira de sobrepor os sistemas de armazenamento da perspectiva do usuário até que a migração seja concluída, mas eu simplesmente não tenho o conhecimento de como fazer isso se for possível.

    

Answer 1

Você pode fazer isso com algo como Aufs ou Unionfs .

Ambos os sistemas de arquivos são sistemas de arquivos "union". Você faria algo como

• Monte o antigo NAS em /mnt/old
• Monte o novo NAS em /mnt/new
• Monte o sistema de arquivos da união em /mnt/nas com /mnt/new na parte superior de /mnt/old .
• Qualquer acesso a /mnt/nas/foo/bar procurará primeiro /mnt/new/foo/bar e, se não estiver lá, voltará a /mnt/old/foo/bar . Se você modificar o arquivo, ele copiará o original de /mnt/old para /mnt/new e, em seguida, modificará a versão /mnt/new .
• Após a montagem do sistema de arquivos da união, você pode executar um rsync de /mnt/old a /mnt/new . Isso pode ser feito enquanto o sistema está ativo. Acessar /mnt/nas vai começar a pegar os arquivos de /mnt/new enquanto o rsync os coloca lá.

Answer 2

Que tal continuar assim:

1. 1º Rsync
2. Faça a resposta do qmail 421 Service not available, closing transmission channel no banner
3. 2º Rsync
4. Restaurar a configuração original do qmail (ou mudar para outro servidor, não sei se consegui essa parte)

Dessa forma, você confiaria no fato de que os clientes tentarão mais tarde para entregar o e-mail.

    

Answer 3

Eu não acho que você será capaz de evitar uma grande quantidade de tempo ocioso, alterando seu back-end de armazenamento, mas há opções. As melhores opções, no entanto, seriam adaptadas às suas necessidades e ambiente.

Se você não excluir aleatoriamente os e-mails, deverá interromper as gravações no sistema de armazenamento, respondendo 421, 450 ou 452. Pessoalmente, eu escolheria 450 "Caixa de correio do usuário indisponível".

Então, eu faria o Rsync, seguido pelo retorno de 450, seguido pelo rsync e, finalmente, o armazenamento mudaria.

Lembre-se de que o email não é confiável. Deveríamos apenas percebê-lo dessa maneira. Uma falha em aceitar uma mensagem significa que o servidor que está enviando a mensagem para você deve tentar novamente. Normalmente, isso seria a cada 4 horas por 24 horas, mas isso é apenas "normal" e não uma regra.

Como um aparte, se você não estava usando o NFS (ou se o servidor NFS é acessível assim), você poderia tentar colocar o armazenamento em algum tipo de cluster, apenas adicionando o novo armazenamento ao cluster e removendo o armazenamento antigo. Isso pode ser feito com algum tipo de RAID (se estiver na mesma máquina) ou com algo como o DRBD. Idéia sendo que você acabou de seguir o caminho de atualização do servidor normal de adicionar um novo servidor para o cluster, dar tempo para "pegar" e, em seguida, remover o servidor antigo.