Armazenamento distribuído e computação [fechado]

1

Prezada comunidade do Serverfault,

Depois de pesquisar vários sistemas de arquivos distribuídos para implantação em um ambiente de produção com o objetivo principal de executar a computação distribuída em lote e em tempo real, identifiquei a lista a seguir como candidatos em potencial, principalmente em maturidade, licença e suporte:

  • Ceph
  • Lustre
  • GlusterFS
  • HDFS
  • FhGFS
  • MooseFS
  • XtreemFS

As principais propriedades que nosso sistema deve exibir:

  • um código aberto, licenciado liberalmente, mas pronto para produção, por ex. uma solução madura, confiável, comunitária e comercialmente suportada;
  • capacidade de executar em hardware comum, de preferência, ser projetado para isso;
  • fornece alta disponibilidade dos dados com maior foco nas leituras;
  • alta escalabilidade, portanto, operação em vários datacenters, possivelmente em escala global;
  • remoo de pontos icos de falha com a utilizao de replicao e distribuio de (meta) dados, e. fornecer tolerância a falhas.

Os pontos de sensibilidade que foram identificados e resultaram nas seguintes perguntas são:

  1. transparência para a camada / aplicação de processamento em relação à localidade dos dados, por ex. saber onde os dados estão fisicamente localizados em um nível de servidor, principalmente para alocação de recursos e processamento rápido, alto desempenho, como isso pode ser feito? Você, por experiência própria, sabe quais soluções fornecem essa transparência e até que ponto?
  2. A conformidade, ou conformidade, do posix
  3. é mencionada nas páginas wiki da maioria das soluções listadas acima. A questão aqui é principalmente, quão relevante é o suporte para o padrão posix? O Hadoop, por exemplo, não é compatível com o design do posix, quais são os prós e contras?
  4. sobre a diferença entre a operação síncrona e assíncrona de um sistema de arquivos distribuído. Embora um sistema de arquivos distribuídos síncronos tenha a preferência por causa da confiabilidade, ele também impõe certas limitações com relação à escalabilidade. Qual seria, da sua especialidade, o caminho a seguir nisto?

Estou ansioso por suas respostas. Desde já, obrigado! :)

Com os melhores cumprimentos,

Tim van Elteren

    
por Tim van Elteren 28.10.2013 / 15:22

2 respostas

1

Parece que você já fez muito trabalho aqui. Com relação aos seus principais requisitos, todos os sistemas de arquivos que você identificou os atendem até certo ponto. Essas são coisas que sistemas de arquivos distribuídos fazem em virtude de serem sistemas de arquivos distribuídos.

O único requisito que merece discussão adicional é o licenciamento - isto é, presumivelmente, uma consideração de negócio pela sua empresa, e serve para eliminar candidatos válidos que não são desejáveis para negócios razões. Esse é um conjunto de escolhas que você precisa fazer internamente em consulta com o resto da sua empresa, e parece que você já sabe o que quer lá.

Não podemos dizer qual sistema de arquivos usar (você precisará fazer mais pesquisas, e alguns testes / simulações de laboratório certamente seriam aconselháveis - tire proveito da virtualização e da infinidade de hipervisores gratuitos!), mas Eu posso te dar uma pequena visão sobre seus pontos de sensibilidade "

Transparency to the processing layer / application with respect to data locality, e.g. know where data is physically located on a server level, mainly for resource allocation and fast processing, high performance, how can this be accomplished? Do you from experience know what solutions provide this transparency and to what extent?

Os sistemas de arquivos distribuídos são, em geral, transparentes para o restante do SO (acima da camada do sistema de arquivos). O sistema de arquivos lida com a distribuição dos dados para vários nós, replicando-os para tolerância a falhas e movendo-os para / de máquinas clientes - seu sistema operacional apenas o trata como qualquer outro sistema de arquivos.

Qualquer sistema de arquivos distribuído que não forneça este nível de abstração é inaceitável na minha opinião: os sistemas cliente não precisam precisar para saber como o FS distribuído funciona sob o capô mais do que eles precisam saber a organização do disco local de um servidor NFS.

As considerações de desempenho são uma questão separada - cada sistema de arquivos que você mencionou acima pode ser ajustado de alguma forma. O melhor conselho aqui é "Faça seus próprios comparativos de mercado com base em sua carga de trabalho" , mas você também pode ver os benchmarks publicados para uma idéia do que você pode esperar.

POSIX compliance, or conformance, is mentioned on the wiki pages of most of the above listed solutions. The question here mainly is, how relevant is support for the POSIX standard?

Só você pode responder à questão da relevância (com base em suas necessidades), mas como um Unix old-school eu posso dizer que espero que os sistemas de arquivos em um host Unix / Linux estejam em conformidade com a especificação POSIX - particularmente no áreas mais visíveis (restrições de nome de arquivo, permissões, ACLs).

O Princípio de Menor Conforto também determina que em um sistema Unix ou Linux seus sistemas de arquivos devem estar em conformidade com o padrão POSIX, e expor permissões e ACLs através das ferramentas padrão do sistema operacional, então eu consideraria que um voto strong favorece o uso de um sistema de arquivos distribuído com uma interface compatível com POSIX.

What about the difference between synchronous and asynchronous opeartion of a distributed file system. Though a synchronous distributed file system has the preference because of reliability it also imposes certain limitations with respect to scalability. What would be, from your expertise, the way to go on this?

Novamente, somente VOCÊ pode impedir que incêndios florestais façam essa chamada.

Como você determinou corretamente, sistemas de arquivos distribuídos síncronos têm algumas preocupações de escalabilidade (principalmente em relação ao desempenho gravação ). Eles também têm a vantagem da consistência strong.
Sistemas de arquivos distribuídos assíncronos quase sempre têm melhor desempenho, mas vêm com um nível inerente de risco - geralmente uma chance maior de inconsistência de dados no cluster, ou perda de dados através de pontos únicos de falha transitórios enquanto os dados estão sendo sincronizados / replicado.

Do meu ponto de vista (ser um cara do Unix da velha guarda), a consistência e a estabilidade superam o desempenho. Há uma citação maravilhosa enterrada na palestra de McKusick sobre a história da FFS , que é algo para o efeito de "Sistemas de arquivos tem que acertar porque os usuários ficam muito chateados quando você perde seus dados "- O corolário no mundo dos negócios / ambientes de produção é que os administradores são demitidos quando perdem dados que valem milhões de dólares, portanto demorando alguns milissegundos para garantir que os dados é devidamente replicado através do sistema de arquivos distribuído faz muito sentido para mim, e eu preferiria usar um DFS síncrono, a menos que houvesse um muito bom motivo para não fazê-lo.

    
por 13.04.2017 / 14:14
0

Com que rapidez você precisa ler? E qual a importância da escalabilidade global?

Apenas no topo da minha cabeça, o Lustre pode ser rápido, mas esse é o único recurso tem da sua lista.

Há duas coisas que sei que atendem aos seus requisitos.

Xrootd - Somente leitura global, HA global, amplamente utilizado na comunidade científica.

link

OpenAFS - existe há muito tempo e é amplamente utilizado no ensino superior.

link

Nenhum deles terá a velocidade de leitura de um sistema Lustre ajustado corretamente, mas ambos podem ser dimensionados para implantações em todo o mundo. O que eu sei do resto do software em sua lista é que ele é mais adequado para acessar em um único data center.

    
por 28.10.2013 / 15:54