O que usar para armazenamento de arquivos compartilhados baseado em software?

5

A situação: configurando um balanceador de carga

Atualmente, temos todos os nossos servidores (rodando o CentOS Linux) em pares em nosso data center: cada servidor tem um servidor de espelhamento. Não empregamos qualquer balanceamento de carga no momento, portanto, o servidorA obtém todo o tráfego e, quando ele falha (hardware ou software), podemos alternar rapidamente para o servidorB, configurando o endereço IP do servidorA no servidorB. Estamos usando a replicação master / master do MySQL (embora pudéssemos simplesmente usar a replicação master / slave para a configuração atual) e o rsync para manter os arquivos vhost em sincronia (serverA syncs to serverB).

Isso está funcionando bem para nós, mas é bastante ineficiente, já que temos 50% do seu hardware sem fazer nada até que uma máquina falhe. Estamos pensando em colocar balanceadores de carga na frente dos pares de servidores para que possamos dividir a carga para ambas as máquinas e também adicionar servidores extras por cluster.

O problema: compartilhamento de armazenamento de arquivos

Configurar isso provavelmente não levará muito mais do que colocar um balanceador de carga na frente de cada par de servidores e, em seguida, dividir o tráfego para cada servidor do par. Exceto por uma coisa: armazenamento de arquivos. Atualmente, o rsync 'empurra' as mudanças de serverA para serverB, mas não o contrário. Podemos configurá-lo para que o rsync também seja executado de serverB para serverA, mas o problema é que o rsync nunca sabe se deve criar ou excluir um arquivo que exista no serverA, mas não no serverB. Eu olhei para Unison , mas esse projeto parece ter sido descontinuado.

A pergunta: qual é a melhor solução para armazenamento de arquivos compartilhados baseado em software?

Então, estou procurando uma solução diferente. Por favor, note que eu não quero adicionar mais hardware (então nenhuma solução NAS / SAN). Lembre-se também que precisamos de uma baixa quantidade de armazenamento (abaixo de 500 GB) por cluster e que todos os servidores estejam na mesma rede local. Temos uma solução de back-up decente no local (backups a cada 3 horas).

Eu tenho procurado DRBD e isso parece se encaixar bem em nossa situação, mas eu não tenho experiência com isso . O DRBD é o caminho a percorrer para nós? Por favor, compartilhe sua experiência com esta e outras soluções semelhantes. Quaisquer armadilhas para pensar? Estou no caminho certo? Por favor, me ilumine:)

    
por vincent.io 01.11.2011 / 10:59

3 respostas

2

O DRBD é ótimo.

As coisas boas:

  • Ele faz um trabalho magnífico na replicação de dados
  • O DRBD impediu em alguns casos o desastre, quando descobriu que o volume já estava montado no outro nó, o que os volumes brutos que recebemos de uma SAN não conseguem nos informar.
  • O Heartbeat já tem um ótimo suporte para o DRBD.

Os desafios:

  • Lembre-se de monitorá-lo corretamente, para que você descubra cérebros divididos quando eles acontecerem - e possa lidar com isso.
  • O DRBD não pode ser montado em ambos os servidores sem um sistema de arquivos habilitado para cluster na parte superior - não tenho nenhuma experiência com essa parte.
  • É fácil "DOS" configurar os servidores configurando o DRBD para usar toda a largura de banda disponível para sincronizar os discos. Basta configurar para um rendimento menor e você está bem.

Para montar o "mesmo sistema de arquivos" em vários nós, continuamos voltando ao NFS, embora continuemos testando várias soluções para ele. Uma configuração que eu não tenho nenhum problema em ter em produção é o NFS em cima do EXT4 em cima do DRBD. Eu não ousaria fazer isso com os sistemas de arquivos do banco de dados, mas tudo bem para o wwwroot.

    
por 01.11.2011 / 11:20
1

O DRBD espelha os dados em tempo real, de forma transparente. Por favor, observe alguns pontos abaixo:

  • Você precisa de um sistema de arquivos em cluster para o modo dual primário. OCFS2 é apenas suportado pelo CentOS 5. Se você estiver usando o CentOS 6, você deve usar GFS2 em vez disso.
  • Embora todo o servidor esteja na mesma rede local, eu ainda Recomendamos conectar com um cabo crossover.
  • Você deve ter um mecanismo de monitoramento para detectar divisão cérebro por exemplo: Nagios check_drbd plugin.
  • Não se esqueça de medir e otimizar DRBD desempenho

Se você quiser configurar 3 ou 4 nós, dê uma olhada:

por 01.11.2011 / 11:53
0

Por que você não configura dois (ou mais) serviços por cluster e permite executar um em cada lado por padrão?

    
por 01.01.2012 / 21:43