instala o Gluster dentro de uma VM ou configura uma VM no topo do Gluster?

2

Estou configurando um servidor da Web de distribuição geográfica geograficamente distribuída de alta disponibilidade , using multiple A-records para o seu domínio . No momento, estou mais preocupado com a alta disponibilidade: "Quando eu desconecto um cabo de alimentação, cada navegador ainda pode ver meu site" - do que a velocidade.

O software do servidor da web é executado dentro de uma máquina virtual por caixa física. (Realmente importa qual servidor web e hipervisor eu estou usando? Em caso afirmativo, estou usando atualmente o Apache e o VirtualBox)

Alguém recomendou que eu despejasse o atual sistema doméstico horrivelmente complicado que eu planejava usar para manter os servidores da Web sincronizados e substituí-lo pelo Gluster.

Qual dessas alternativas é melhor?

  1. O sistema operacional host executa somente o hipervisor e armazena somente a imagem de disco da VM. Dentro de cada máquina virtual, instale o software Gluster, configure um ponto de montagem GlusterFS apontado para uma pasta (tijolo) dentro da imagem de disco da VM e use esse ponto de montagem (ou uma pasta dentro dele) como a raiz da Web.

  2. O SO do host deve executar somente o hipervisor e armazenar ambos a imagem da VM e separadamente uma pasta (brick) que eu permita que a VM acesse. Dentro de cada máquina virtual, instale o software Gluster, configure um ponto de montagem GlusterFS apontado para o bloco fora da imagem de disco da VM e use esse ponto de montagem (ou uma pasta dentro dele) como raiz da Web.

  3. O sistema operacional host deve executar o hypervisor e o Gluster. No SO host, configure um ponto de montagem do GlusterFS apontado para alguma pasta (brick) em outro lugar no disco físico real. Permita que a VM acesse o ponto de montagem do GlusterFS como a raiz da web. (Não é necessário instalar o software Gluster dentro da máquina virtual).

  4. O sistema operacional host deve executar o hypervisor e o Gluster. No SO host, configure um ponto de montagem do GlusterFS apontado para alguma pasta (brick) em outro lugar no disco físico real. Como os dois servidores da Web devem ser idênticos, informe ao hipervisor para armazenar a imagem do disco virtual dentro do ponto de montagem do GlusterFS.

  5. Outra coisa?

Eu suspeito que alguém que sabe mais do que eu sobre Gluster pode dizer imediatamente: "Se você fizer # 4, (alguma coisa horrível acontecerá), e (algum outro número) causa (alguma outra coisa horrível) ... então o única opção que realmente funciona é (o único número restante) ". (Ou seja, não acho que essa seja uma questão subjetiva).

(A "otimização" mencionada em Alguém pode explicar essa configuração do GlusterFS? poderia aplicar-se a qualquer uma destas alternativas).

    
por David Cary 28.10.2014 / 07:29

2 respostas

5

A menos que as coisas mudem desde o ano passado, eu aconselho não usar o AFR glusterfs em hardware geograficamente diferente. Ele não manipula bem a latência e a falha em especificar o subvolume de leitura fará com que ele seja aleatoriamente (aparentemente aleatoriamente, não é aleatório) para tentar ler de um bloco remoto. Como um teste, configure seus dois nós mais latentes na replicação gluster e, em seguida, tente touch testfile && time stat testfile nesse sistema de arquivos para ver quanto tempo cada FS operacional levará, no mínimo. Mesmo que você tenha especificado que seu aplicativo é share-nothing, ele ainda fará verificações de verificação de bloqueio e de coerência para você, o que significa pesquisar metadados de todas as outras réplicas.

Depois de executar o teste, se você ainda quiser usar o gluster, isso é o que você perguntou:

Se você usar # 4 e tentar montar a imagem da VM em várias VMs ao mesmo tempo, terá problemas de consistência no FS. Os sistemas de arquivos normais do Linux não suportam armazenamento de backup volátil.

A passagem do sistema de arquivos, como em # 2, tem um desempenho ruim em todos os sistemas de virtualização que eu tentei. Você é muito melhor usar o NFS como um transporte em vez de algo como 9p virtio (kvm) ou qualquer que seja o equivalente para o vbox; O repasse do windows-host fs para o vbox é bastante ruim (leia-se: lento, frágil), imagino que o equivalente hospedado no Linux seja semelhante. Mesmo se você obtiver o repasse de fs funcionando, as probabilidades são de que ele não suportará xattr, o que é requerido pela replicação de glusterfs. Historicamente, ter o NFS configurado para atributos estendidos tem sido uma dor, mas você pode ter mais sorte com o NFSv4. Esta abordagem é repleta de armadilhas, eu iria evitá-lo.

# 3 tem alguma promessa. Configure o gluster no host e, em seguida, execute o listener de cliente do NFS gluster e faça com que a VM se conecte a ele. Ele também é o mais facilmente convertido quando você o descobre. A. não quer usar VMs e / ou B. não quer usar glusterfs.

# 1 é igualmente viável, mas não tem vantagem sobre o bare metal - quaisquer ganhos de segurança são efetivamente negados, já que você diz que é para um sistema de aplicativo único. Para esse assunto, também não # 3. A única diferença com este é que você pode usar o driver nativo do linux para glusterfs. Você pode querer configurar um disco virtual diferente para o bloco para que você possa desanexá-lo se você precisar refazer a imagem da VM sem repopular seu bloco.

    
por 19.11.2014 / 21:10
4

Eu diria que perder tudo. Não virtualize isso com o VirtualBox e não use nenhum sistema de arquivos de cluster / replicação. Camadas de complexidade geralmente acabam sendo camadas de apenas isso, complexidade, bugs, lentidões e instabilidades.

Mantenha a simplicidade. Execute o Apache no bare metal e use o NFS ou o rsync para mover seus dados entre seus locais.

    
por 16.11.2014 / 22:08